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Digital Equipment Computer Users Society 



DECUS, U. S. Chapter 
219 Boston Post Road, (BP02) 
Marlboro, MA 01752 


U. S. Activities (617) 480-3259 or 3302 
Finance & Admin. (617)480-3634 
Library (617) 480-3521 


Dear SIGs NEWSLETTERS reader: 

This month I will continue a long tradition, (started last month,) by reporting on topics ot 
general interest to the readers. This column may not always appear, but it will appear 
when I find I have problems with this 21-ring circus and feel that the problems directly 
affect you, the subscriber. 

This month, I will be talking about the problems with our subscription services, (or more 
accurately, with our REsubscription services.) Currently our subscription service leaves 
much to be desired. Much of the problem revolves around our current subscription soft¬ 
ware. Eventually we WILL be getting new software, but for now I will be talking about 
some short-term fixes and workarounds. Anyway, the major problems I see are: 

O It takes a long time to start a subscription. 

O It's not easy to tell when your subscription expires, or when you should re-subscribe, 

and we don't make it easy enough to re-subscribe. 

The simplest thing that is wrong with subscribing is that the subscription form (and 
DECUS membership form,) are included in the "How To" Submit an Article section. 
Starting this month, they will have their own section, clearly marked as such on the front 
cover, so you can FIND THEM. 

The simplest thing that is wrong with renewing is that we only send you one renewal 
form. (Yes, only one form is not enough, most magazines send at least 3 forms.) We're 
working on that, soon you will be getting multiple forms, so if the U S Snail loses one, you 
still have a chance. Anyway, until we get this working, there are some simple things you 
can do. 


As far as general questions about renewal, here are some typical questions about subscrip¬ 
tions, along with some (hopefully helpful) answers. 


Question: 


Answer: 


Question: 


I found the form in the newsletter and sent it in. When will I get my first (or 
renewal) newsletter? 

When your form gets to DECUS, it takes a couple of days to process, (maybe 
a little longer right around Symposium.) Usually about a week elapses from 
the time you mail your subscription. Let's say the subscription is processed 
on April 15th. You will eventually know this date because it is printed on 
your mailing label. (The first 6 digits are your DECUS number, the next 6 
are the date in the format yymmdd.) 

On about the first of the month, your subscription is counted for the next 
production run of the newsletter. But since we start working on the JUNE 
issue on the first of May, you end up getting your first issue with the June 
issue, a month and a half later. (Not the next issue as it states on the 
subscription form.) 

When should I renew? 
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Answer: 

Question: 

Answer: 


Question: 

Answer: 


Question: 

Answer: 


Question: 

Answer: 


Question: 

Answer: 


Question: 

Answer: 

Question: 

Answer: 


You should have received a renewal notice and sent it in by the date one 
year later than the date on your subscription. 

What should I do if don't receive a renewal form? 

If necessary, you can tear out the form from the newsletter and send it in, 
but mark it clearly "RENEWAL". (Yes we don't have separate boxes to check 
for "NEW" and "RENEWAL" on the form.) 

Can I subscribe or renew by phone? 

Yes, if you can pay by MasterCard, VISA, American Express or DinersClub/ 
Carte Blanche®. Just call (617) 480-3659, and have your membership 
number ready. (Just to complicate things further, after July 15th, the tele¬ 
phone company is changing the Marlboro area code to 508.) 

I renewed my subscription, but the date on my label didn't change, why 
not? 

Our current subscription software can't handle renewals. What happens is 
that your renewal effectively gets entered as a whole NEW subscription. 
When your current subscription runs out, your new one starts automatically. 
You can tell because the date code on your label will change when your new 
one starts. 

I think I renewed twice this year, once by mail and once at the fall sympo¬ 
sium. How can I tell? 

Like the previous answer, renewals get queued up behind current subscrip¬ 
tions. If you renewed twice, you may have a couple of subscriptions stacked 
up. ( A few of our subscribers have a couple of years stacked up!) If in 
doubt, call the office. 

I want a different address on my newsletter than the one I get regular 
DECUS mailings sent to. Why can't you do that. 

All DECUS mailings are tied into a master address data file, keyed to your 
DECUS membership number. This address must be the same for Library 
mailings, DECUSCOPE, Newsletter, etc. 

I submitted a change of address using the form on the back cover. How long 
should that take? 

The same as a subscription entry or renewal. About a month and a half. 
For any other problems, what should I do? 

When in doubt, call. Once again, the magic number is, (617) 480-3659. 
Remember, after July 15th, the area code changes to 508. 


That's all for this month folks, hope this information has been helpful. 
Frank "Ringmaster" Borger 
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Letter from the Editor 


By: Dale Hutchison 

Cummins Engine Company 
4720 Baker Street Extension 
Lakewood, New York 14750 


Its been a few months since you’ve heard from me. Glad to see that you are still reading the newsletter. 
Remember, even you can have your article published in the DAARC SIG section of the newsletter. Forward 
your article to me at the above address. Be sure to include your name, address and phone number. The 
phone number is for me, just in case I have a question regarding your article. 

In this issue we have another article from Jim Duba. His article is about a project he has worked on, 
involving the use of a personal computer in a computer integrated manufacturing application. 

Note: For those of you that were unable to attend the spring symposia in Cincinnati, you can order a copy 
of the Proceedings. Contact the DECUS Office 

219 Boston Post Road 
Marlboro, MA 01752-1850 


Until next month. 

AN APPLICATION OF CIM 
USING A PERSONAL COMPUTER 

By: Jim Duba 

Cummins Engine Company 
4720 Baker Street Ext. 

Lakewood, New York 14750 

1 Purpose 

The purpose of this project was to measure hole location and diameter in a part with reamed and drilled 
holes. The results of the measurements are intended to be used in adjusting machine performance on the 
spot and for evaluating long term performance. 

2 How It Works (in general) 

The part has two holes all the way through. The start of each hole is considered a separate hole. This 
means that the left hole is numbered hole one on the back of the part and hole four on the front of the part. 
They are numbered one through four. Hole one is coaxial with hole four and hole two is coaxial with hole 
three. Holes one, two, and three are the same diameter. Hole four is slightly smaller. We are concerned 
with measuring the diameter of each hole, the location of each hole in the part, and the distances from the 
center of holes two and three to the center of hole four. 

The part is first placed in a gauging fixture, then probes are inserted through the fixture into the part. The 
fixture holds the probe securely in place (the shoulder of the probe is held in place by the gauging fixture). 
Near the end of the probe there is a small, spring-loaded button that presses against the side of the hole 
in the part. The distance it sticks out is changed into an electrical signal that is sampled and converted into 
a number in a personal computer. The probe is rotated around the hole by the operator and the signal is 
sampled every ninety degrees. The numbers obtained from measuring a part this way are compared with 
the numbers obtained by measuring a master with known dimensions in an identical fashion 
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3 Electrically - Very Briefly 

The button on the probe actuates a transducer. This transducer feeds an amplifier that is connected to an 
analog to digital conversion board in an AT compatible. The transducer amplifier produces a voltage that is 
proportional to the distance the button on the probe has moved. This voltage is amplified and then 
converted into a number between -2047 and +2047 by an analog to digital converter card in the AT 
compatible. The mechanics and electronics combine to produce numbers that get larger the further the 
probe is pushed in. 

4 Calibration 

Calibration is the process of relating the electrical signals to a linear measurement unit such as millime¬ 
ters. The small button on the probe tip is depressed a known amount, usually with a gauge block. This 
signal value can then be used in converting the voltage readings into actual measurements. 

For example, lets assume we place the probe between two pieces of metal, the button is slightly depressed 
and produces a reading of 1947 in the personal computer. A one mm gauge block is inserted between the 
button and its piece of metal which produces a reading of 1352. This means that each unit of measurement 
from the analog to digital converter is worth .00168mm. 

5 Mastering 

A part with precisely known dimensions known as the master, is placed in the gauging fixture. The 
operator goes through the same measuring process described below for a part. The numbers obtained from 
the probe tips are saved and when a part is measured, the actual values obtained from the part are 
compared to the numbers obtained from the master. Since the master has known dimensions and the probe 
has been calibrated, the dimensions of the part can be calculated. 

6 Taking a Measurement 

This section will only describe the process of taking a single set of measurements for one hole. In actual 
practice, four such measurement sets are taken, one set through each of the holes in the gauging fixture. 
This section is intended only to describe the physical process; the computations will be detailed below. 

The part is clamped securely into the gauging fixture. Because the hole locations are being compared to the 
hole locations of the master, it is important that this is done the same way each time. A probe is inserted 
into the hole with the button down, this is considered zero degrees. The reading from the transducer is 
recorded and the probe is rotated 90 degrees clockwise, to the ninety degree position. The reading is 
recorded and the probe is rotated clockwise another 90 degrees to the one hundred eighty degree position. 
This reading is recorded and the probe is rotated 90 degrees clockwise once more to two hundred seventy 
degrees and the final reading is recorded. A program running on the personal computer prompts the 
operator through each step to insure that the probe is in the right place before it’s sampled. 

7 Calculating the Results 

We’ll assume that we got the following readings from the process described above. It’s not important to 
know the actual dimensions of the master. 

Part 

A - 0 degrees - 1397 
B - 90 degrees - 1351 
C - 180 degrees - 1511 
D - 270 degrees - 1394 

Master 

E - 0 degrees - 1395 
F - 90 degrees - 1588 
G - 180 degrees - 1394 
H - 270 degrees - 1520 

Calibration for this probe is .000459 millimeters per division. 
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7.1 Hole Diameter 

Zero and one hundred eighty degrees are the vertical diameter. Ninety and two hundred seventy degrees 
are the horizontal diameter. E is smaller than A so the master is larger than the part: 

E - A = -2 

G is smaller than C: 

G - C = -117 

This means that the part hole is -119 times .000459 or .0537 millimeters smaller in diameter than the 
same hole in the master. 

The same calculations for the horizontal diameter: 


F - B = 237 

H - D = 126 

237 + 126 = 363 

363 * .00459 = 1.666mm 

which means that the part is 1.66mm larger than the master. 

7.2 Hole Location (Displacement) 

Hole location is a little trickier because the signs are not as intuitive. In this case the directions are the 
same as ordinary Cartesian coordinates. Up (as the part is placed in the fixture) is considered positive Y 
axis, and right is positive X axis. The direction is from the master to the part. So a positive Y means that 
the part is above the master, and a positive X means that the part is to the right of the master. Let’s work 
through the computations with the same hole measurements that were used for hole diameter above. 

At zero degrees, the part is below the master (negative): 

E - A = -2 

and at one hundred eighty degrees, the part is above the master (positive): 

C - G = 117 

Thus the center of the parts hole is: 

.000459 * (-2 + 117) / 2 = .0264mm 

above the center of where the master was. 

Horizontally it works out as follows: 

B - F = -237 
H - D = 126 

.000459 * (-237 + 126) / 2 = -.0255mm 

Which means that the center of the hole in the part is .0255mm left of the center of the hole in the master. 

7.3 Distance Between Holes 

It’s easy to see how the distances between the holes on the part can be calculated knowing the same 
dimensions on the master. Assuming that the hole we just calculated values for, is the left hole and the 
right hole measures -.0132. Then: 

140 - .0132 + .0255 = 140.0123 

gives the distance between the holes in the part. 
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8 Wrapping It Ail Up 

This system is implemented on a standard AT compatible with an A/D card. We are adding a DEPCA kit 
to provide communications to our VAX system where our quality database resides. This will provide 
immediate update of the quality system at the time measurements are made. 

Editors Note: 

The DEPCA kit referred to is a product of Digital Equipment Corporation, used to integrate personal 
computers into a local area network. 
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Contributions 


Contributions for the newsletter can be sent to either of the following addresses: 


Editor, DATATRIEVE Newsletter 
c/o DECUS U.S. Chapter 
Company 219 Boston Post Road, BP02 
Marlboro, MA 01752 


Joe H. Gallagher, Ph. D. 
4GL Solutions 
10308 Metcalf, Suite 109 
Overland Park, KS 66212 


Letters and articles for publication are requested from members of the SIG. They may 
include helpful hints, inquiries to other users, reports on SIG business, summaries 
of SPRs submitted to Digital or other information for members of the DATATRIEVE SIG. 
Machine readable input is highly desirable and machine-to-machine transfer of mater¬ 
ial is preferred, but most anything legible will be considered. However, this news¬ 
letter is not a forum for job and/or head hunting, nor is commercialism appropriate. 


Table of Contents 


DBCOS U. S. Chapter 

SIGs Newsletter, Volume 3, Number 10, June 1988 
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How NOT To Define Your Default Dictionary In DCL. 2 
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Using DATATRIEVE Record Definitions with the SORT/MSRGE Utility .. 6 

VAX RALLY Application Development Topics. 9 


About the authors... 

Bart X. Lederman works in the Advanced Systems Development Group of WU World Communi¬ 
cations in New York City? he holds a Masters of Electrical Engineering in Solid 
State Electronics and Communications from Rennselaer Polytechnic Institute. 
Bart is the Library Committee and PDP-11 Working Group representative of the 
DTR/4GL SIG; a regular speaker at Symposia; the artist for the Wombat Examiner 
and 4GL Dispatch and special projects coordinator for the SIG; a member of the 
DTR/4GL Executive Steering Committee; and a 1984 recipient of the DATATRIEVE 
Greybeards Award. 

Anothony D. Rogers is a principal Software Engineer at Digital Equipment Corporation. 
He has been the VAX RALLY project leader for two years, and has been working on 
the RALLY project for four years. 
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How NOT To Define Tour Default Dictionary In DCL 

B. Z. Lederman, WU World Communications, New York, NY 10004-2464 


I have to work in several different CDD dictionaries during the day, depending upon 
the job at hand. In order to make this easier, I do two things in my LOGIN.COM file. 
First I define the logical name CDD$DEFAULT to point to my desired default diction¬ 
ary: then I define some symbols which make it easier for me to change my default 
dictionary. The relevant section of my LOGIN.COM file USED to look like this: 


$ DEFINE CDD$DEFAULT “CDD$T0P.DTR$USERS.LEDERMAN" 

$! 

$ CDDAI1 :== DEFINE CDD$DEFAULT "CDD$T0P.DTR$USERS.ALLIN1" 

$ CDDHOME :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN" 

This all looks perfectly reasonable and proper, and used to work perfectly well. 
When I logged in, my default dictionary was CDD$ TOP. DTR$USERS. LEDERMAN, and if I 
typed in CDDAI1 at the DCL prompt, CDD$ DEFAULT was redefined to 
CDD$TOP.DTR$USERS.ALLIN1, and so on. 

Everything worked well until I added some additional dictionaries below my normal 
dictionary like this: 

$ CDDDMF :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN.DMF" 

$ CDDACC :== DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN.ACCOUNTING" 

Now, if I typed in CDDACC at the DCL prompt I got the error: 

&DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters \.ACCOUNTING\ 

which didn't seem to make much sense. Worse, if I typed in the DEFINE command at DCL 
level, it worked. 

TSC eventually ran this down, and it is documented somewhere in the VMS documentation 
set that you are not allowed to have special characters in a logical name definition 
unless they are surrounded by quotes, and a period is a special character. Now, the 
definition above appears to be surrounded by quotes, but you are also not allowed to 
have special characters in a symbol definition unless they are surrounded by quotes 
as well, and the ones above are not. In order to insure that the definitions always 
work, I have changed my LOGIN.COM file to look like this: 

$ DEFINE CDD$DEFAULT "CDD$TOP.DTR$USERS.LEDERMAN" 

$! 

$ CDDAI1 :== DEFINE "CDD$DEFAULT ""CDD$T0P.DTR$USERS.ALLIN1"" 

$ CDDHOME :== DEFINE "CDD$DEFAULT " H CDD$TOP.DTR$USERS.LEDERMAN"" 

$ CDDDMF :== "DEFINE CDD$DEFAULT ""CDD$TOP.DTR$USERS.LEDERMAN.DMF"" 

$ CDDACC :== "DEFINE CDD$DEFAULT ""CDD$TOP.DTR$USERS.LEDERMAN.ACCOUNTING"" 

You may well ask, "If there has to be quotes around special characters, why did the 
CDDAI1 and CDDHOME symbols work before the fix?" It appears that there is a hidden 
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bug in VMS/DCL which allows some invalid definitions to work# and the magic number of 
special characters appears to be two. With two periods the definitions work# but 
with three or more they fail. I don't think anyone knows why yet. 

Also note that when a definition is enclosed in quotes# that no lower case to upper 
case translation takes place. In the above examples I don't thin that matters much 
as I believe CDD will itself do the case translation: but in other cases you may have 
to be careful to enter your definition in upper case if the person/program/utility 
which uses that definition is going to search in upper case and is case sensitive. 


Wombat Wizard 


Dear Wombat Wizard: 

I have written a large multi-user# menu-driven application in DATATRIEVE (about a 
dozen domains with about 75 procedures). Within the menu-driveji procedures# all 
domains are readied SHARED except under some special circumstances which don't per¬ 
tain to my problem. Multiple users can work within the menu-driven system without 
any file access conflict. My problem occurs when the boss (who knows enough DATA¬ 
TRIEVE to be dangerous and who has privilege to leave the menu-driven application) 
works in DATATRIEVE interactively. When the boss accesses domains# sometimes my 
menu-driven procedures fail with 

Error using RMS file "FILENAMt.tXI". 

%RMS-E-FLK, file currently locked by another user 

Sometimes the procedure "aborts" and the user is returned to the menu screen (that's 
the good news); other times the procedure continues processing and writes bad data in 
other domains (that's the bad news). With much less frequency# we get the message 

%RMS-I-FLK, file currently locked by another user 
Couldn't change access to readied domain. 

and the procedure continues processing sometimes corrupting the data. 

What can I do to fix this problem? Is there something I can do which will keep the 
boss' interactive sessions from blowing up concurrent menu-driven sessions? Or are 
there some coding changes I can make in the procedure to test for and trap the condi¬ 
tions? 


Signed, 

Confused by simultaneous access 


Dear Simultaneously Confused# 

As you have surmised# your problem stems from conflicting simultaneous RMS file ac¬ 
cess. The READY command is where the problem occurs. 

Most of the time DATATRIEVE programmers and DATATRIEVE end-users operate in a single 
user# single process context. In this situation# one only has to worry about what 
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occurs within that process. In the situation which you have described, multiple 
users are concurrently accessing many domains. This is a much more complex situation 
in which most DATATRIEVE programmers, including the Wombat Wizard, have some diffi¬ 
culties. 

Before we can proceed to the solution to your problem, we need to review the condi¬ 
tions under which simultaneous access conflicts arise. Recall that you can specify 
in the READY command the mode of access to the domain with READ, WRITE, MODIFY, or 
EXTEND and control the access of other users with SHARED, PROTECTED, or EXCLUSIVE. 
It appears that there are 12 possible combinations of "users access" and "other user 
control" to consider. However, WRITE, MODIFY, and EXTEND are essentially equivalent 
(with respect to this analysis); these access modes change (or potentially change) 
the data. READ mode doesn't. Therefore, there are really only six combinations. 
Consider the following six by six table showing where conflicts arise. "OK" means no 
conflict? "X" means conflict and the second READY will fail. 




SHARED 

PROTECTED 

EXCLUSIVE 


R 

WME 

R 

WME 

R 

WME 

SHARED R 

OK 

OK 

OK 

OK 

X 

X 

WME 

OK 

OK 

X 

X 

X 

X 

PROTECTED R 

OK 

X 

OK 

X 

X 

X 

WME 

OK 

X 

X 

X 

X 

X 

EXCLUSIVE R 

X 

X 

X 

X 

X 

X 

WME 

X 

X 

X 

X 

X 

X 


Since you state that all your procedures control the access of others by the use of 
SHARED (you allow all access by others) but the boss causes the problem with inter¬ 
active access (which by default is PROTECTED), the problem is occurring between PRO¬ 
TECTED READ or WRITE with SHARED READ or WRITE. See the area in the box in the table 
above. 

The default access to domains is PROTECTED; this has been the case since the earliest 
version of DATATRIEVE. However, since version 4.0 of VAX DATATRIEVE, it has been 
possible to specify the default access control. The logical DTR$READY_MODE, if spe¬ 
cified, will override the default of PROTECTED. One easy way around your problem is 
to slip the following line of DCL code into your boss' LOGIN.COM file: 

{ASSIGN “SHARED" DTR$READY_MODE 

This will work just fine if your boss only knows how to ready domains without speci¬ 
fying any mode control. However, if your boss is like mine, he is compulsive, unpre¬ 
dictable, and slightly crazy, and this change in his defaults ready mode will not 
completely solve your problem. 

A more realistic way to attack your problem is to modify the DATATRIEVE code in your 
procedures. The apparent unpredictability of your procedures when the file access 
conflict occurs is due to the state of SET ABORT. If SET ABORT is in effect, DATA- 
TRIEVE will abort the remainder of your procedure or command file when 

1. an ABORT statement is executed 

2. a CTRL/Z is enter at a prompt 

3. a logical or syntax error occurs during the execution of a command or statement 
(except the DELETE command) 
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It is the third case which you are experiencing; the *'%RMS—E—FLK 11 error is treated as 
a logical error and your procedure is aborted if ABORT is set. If ABORT is NOT set, 
then you get the error message, but the procedure continues to execute. 

Thus, if you want to make sure that you don't do any processing if you can not gain 
access to a domain, then your procedure should contain a SET ABORT before any criti¬ 
cal READY. If the READY fails, all the other statements and commands will be ignor¬ 
ed . 

Now we have taken care of everything except the case when you get the informational 
message 

%RMS-I-FLK, file currently locked by another user 
Couldn't change access to readied domain. 

In this case, the menu-driven process initially had the domain readied SHARED READ. 
The boss then accessed the domain with a PROTECTED WRITE. Then the menu-driven pro¬ 
cess tried to change the ready access to SHARED WRITE. This last READY fails with 
the error message above and the domain is left in SHARED READ acdess. In this situa¬ 
tion, the error is only an INFORMATIONAL error not a FATAL error. So even if ABORT 
is set, the procedure will not abort! 

There are a couple of work-arounds to this. First (and simplest) is to always ready 
domains in menu-driven application as SHARED WRITE. This will cause the boss' ready 
to fail rather than the menu-driven application's. The disadvantage to this is that 
if the menu-driven application has a record selected (even if the record is not going 
to be changed) there will be a record lock on that record which may block searches by 
other users. Second is to explicitly re-ready the domain with ABORT set. Consider 
the following ways to ready a domain SHARED WRITE: 

! Case 1 ! Case 2 

SET ABORT SET ABORT 

READY F00 SHARED READ 
FINISH F00 

READY F00 SHARED WRITE READY F00 SHARED WRITE 


In Case 1, if the domain FOO is already readied SHARED READ, and the RE-READY fails 
with an INFORMATIONAL error message, the procedure is not aborted. In Case 2, the 
domain is explicitly readied SHARED READ. If someone else has the domain exclusive¬ 
ly, this READY will fail and the procedure will abort. If the ready SHARED READ does 
not fail, then it doesn't matter if the domain was previously ready or not; it is now 
ready. It can then be explicitly FINISHed. Then the following READY SHARED WRITE 
will either succeed or will fail with a FATAL error (rather than an INFORMATIONAL 
error) and abort! 

We have described how to solve your problem; however, the solutions is not very user 
friendly in that the ABORT occurs (protecting the rest of the data base) but no mes¬ 
sage is given (nor can one be given) to the user to alert him/her as to what has 
happened. 

A much "cleaner" solution to this problem would be to get the DATATRIEVE developers 
to add a new function to DATATRIEVE which would report the status of domains. When 
you type SHOW READY, you get a report of the status of all readied domains. That 
looks like: 
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DTR> ready foo 
DTR> show ready 

FOO: Domain, RMS indexed, protected read 


If we had a function like FN$DOMAIN_STATUS(domain__name) which would return the status 
"Domain, RMS indexed, protected read" or the string "Not ready", then you could use 
the following type of DATATRIEVE code: 

SET NO ABORT 

READY FOO SHARED WRITE 

SET ABORT 

if (fn$domain_status(FOO) not containing "shared write") then begin 
print "Domain FOO could not be readied for write access." 
abort "Aborting procedure." 
end 


I guess someone will have to put in a PIR (product improvement request) for such a 
function. Hope this solves your problem and your domains can be simultaneously ac¬ 
cessed . 


Signed, 

The Wombat Wizard 


Using DATA1RIEVE Record Definitions with the SORT/MERGE Utility 

Bart Z. Lederman, WU World Communications, New York, NY 10004-2464 


Most VMS users are (I hope) familiar with the SORT/MERGE utility. Apparently, not so 
many people are aware that this utility can also change file layouts (delete fields 
or change the positions of fields in records), eliminate duplicate records, change 
file organization (sequential to indexed or variable length to fixed length records), 
and it can often perform these functions faster than DATATRIEVE. 

One of reasons SORT/MERGE isn't used as often as it might be is that in order to do 
such functions as record re-organization, you have to describe where all the fields 
are in the record. This normally means writing a sort specification file with the 
fields identified by size and position in the record. Laying out a record and count¬ 
ing bytes to find the locations of all of the fields is tedious and error-prone. 

Fortunately, if you have a record definition for your file in the CDD such as a DATA¬ 
TRIEVE record definition, then SORT/MERGE can use the same definition and you don't 
have to try to figure out where the fields are; you can simply use the same field 
names you used in DATATRIEVE. This feature is not very well documented in the 
SORT/MERGE manual, and there are a few oddities to using it. So I will describe what 
I have learned about it. 

Consider the following very simplified DATATRIEVE record definition named 
ORDER_RECORD in CDD node CDD$TOP.SHIPPING 
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01 0RDER_REC. 

10 0RDER_NUMBER USAGE INTEGER. 
10 SHIP_T0. 

20 NAME PIC X(10). 

20 ZIP_CODE PIC 99999. 

10 $OLD_TO. 

20 NAME PIC X(10). 

20 ZIP CODE PIC 99999. 


Suppose I want to sort this file by QRDER__NUMBER. First I must create a sort speci¬ 
fication file which tells sort where this record is and what field to use for sort¬ 
ing. I will call this EXAMPLE1.SRT, and it will contain the following: 

/CDD_PATH_NAME="CDD$T0P.SHIPPING.0RDER_REC0RD* 

/KEY=(0RDER_NUMBER) 

Now all I have to do is tell SORT to use this specification when it sorts my file. 
For example: 

$ S0RT/SPEC=EXAMPLE1 INPUT.FILE OUTPUT.FILE 

where INPUT.FILE and OUTPUT.FILE are of course the names of the files which have my 
data to sort and the file into which the data will be placed; they can both be the 
same name. Notice that I didn't have to put any ”/KEY=( xxx)" qualifiers on the DCL 
command line because there is one in the specification file. 

Special handling for group fields 

In the above example record, there are two ZIP_CODE fields. A problem arises in 
sorting one of these fields, because SORT/MERGE doesn't know quite as much about CDD 
records as other products (or as much as it should know). You can't just specify a 
path name such as: 

/KEY=(S0LD_T0. ZI P__C0DE) 

as you would in DATATRIEVE or other languages. Fortunately, there is a work-around 
suggested by a member of the CDD support group in the Telephone Support Center that 
appears to function properly (at least the times I've tried it), and that is to pre¬ 
tend to sort on the group header. The sort specification file would become: 

/CDD_PATH_NAME="CDD$T0P.SHIPPING.0RDER_REC0RD“ 

/KEY=(S0LD_T0) 

/KEY=(ZIP_C0DE) 

Even though SOLD_TO isn't a "real" field, this seems to make SORT/MERGE happy and 
allows it to find the right ZIP_CODE. I've also sent in an SPR on this, and perhaps 
some day this may be improved. 

Reorganizing files / extracting fields 

As an example of how SORT/MERGE can be used to reduce data, I decided to try produc¬ 
ing a subset of the system authorization file. 1 This would reduce the size of the 


1/ A record definition for SYSUAF.DAT is in the DTR/4GL SIG Library collection and 
appears in "Accessing SYSUAF.DAT and QUOTA. SYS with VAX DATATRIEVE", by Donald E. 
Stern, Jr., DECUS U. S. Chapter SIGs Newsletters, Volume 1, Number 2, pp. DTR-12 - 
DTR-14, October 1985; and an Errata in Volume 1, Number 4, pp. DTR-17 - DTR-18, 
December 1985. 
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record, eliminate blank spaces and fields I don't need, and in this example allows 
extraction of only "nonsensitive" data. It also allows me to experiment with the 
data without accidentally changing or locking the system authorization file. My sort 
specification file SYSUAF.SRT looks like this: 

/CDD_PATH_NAME="CDD$T0P.DTR$USERS.SYSTEM,SYSUAF_RECORD" 

/KEY=(USERNAME) 

/DATA=USERNAME 
/DATA=ACCOUNT 
/DATA=OWNER 
/DATA=DIRECTORY 
/DATA=LOGFAILS 

/DATA=DATE_LAST_I NTERACTIVE_L0G IN 

and the DCL command I used with this file was 

$ SORT/STAT/SPEC=SYSUAF SYS$SYSTEM:SYSUAF.DAT SYSUAF.SEQ 

I received an error message from SORT because the input file is indexed and I had not 
created a blank indexed file into which SORT could insert the data; so it went ahead 
and created a sequential file, which happened to be what I wanted anyway. If I had 
used an additional switch to tell SORT that I wanted a sequential file the error 
message would not have been produced. Note again that because a CDD record 
definition is used, all that is necessary to produce a reformatted output record is 
to name the desired fields in the desired order. Also note that when you are 
converting from one record layout to another, the one you use in the sort 
specification file is the INPUT file record layout. 

Benefits 

There are times when a domain contains a large number of records, and each record 
contains many fields; yet a report has to be done on only a few fields, or must be 
done by sorting the data on a field which is not a key, or by sorting in descending 
order when the key is ascending. In these situations, it may be faster to sort the 
data into a sequential file with SORT/MERGE, and then report on it without sorting in 
DATATRIEVE. This is especially true if the /DATA option is used in SORT/MERGE to 
pull out only the fields which are actually needed, and this can in turn save a 
significant amount of disk space. 

Special note for PDP-11 users 

There is a SORT-11 utility available for RSX (and, I think, RSTS) which has most of 
the functionality of VMS SORT/MERGE, especially SORT-11 Version 3. Unfortunately, it 
can't read DATATRIEVE dictionaries, so you have to describe the fields individually 
using the /FIELD command and giving the position and size. However, it is often well 
worth the effort especially when reporting large domains. . DTR-11 often runs out of 
pool space when doing complicated reports, and especially when sorting large domains. 
By using SORT-11 first to put only the necessary fields into a sequential file which 
is already properly sorted, the DATATRIEVE report will take much less time to execute 
and reports which would have failed for lack of pool space may be obtained. 
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VAX RALLY Application Development Topics 


Anthony D. Rogers 


VAX RALLY is a fourth generation application de¬ 
velopment system from Digital Equipment Cor¬ 
poration. This article is the first in a series that 
will describe an assortment of special techniques 
that customers have found useful when develop¬ 
ing applications with RALLY The theme of this 
article is form/report formatting. The following 
topics are covered: computed text fields, multi- 
line text fields, floating aggregate fields, and 
first/middle/last formatting. 


Digital Equipment Corporation 

110 Spitbrook Road (ZK02-2/K29) 
Nashua NH, 03062 


Computed Text Fields 

One technique for use with VAX RALLY that is useful in 
many applications is to define a computed field that concate¬ 
nates data fields and string constants together. Take as an 
example an employee name that is defined in the database 
as 3 text fields, FIRST, MIDDLE, and LAST. That’s fine 
for data entry and is especially useful for queries, since it 
allows people to query on the different fields separately, but 
on reports, people normally prefer to see names displayed 
in a more natural way. 

The solution to this is very simple. Define a computed 
field to display the formatted name, and marie the three data 
fields as non-displayed. The computation is defined using 
an ADL (Application Development Language) procedure: 

fr.formatted_name := 
fr.first ||'' II 
fr.middle | | ' . ' | | 

fr.last; 

The double bar ("I I") is the ADL concatenation operator. 


Anthony D. Rogers is a Principal Software Engineer at Digital Equipment Corporation. 
He has been the VAX RALLY project leader for two years, and has been working cm 
the RALLY project for four years. 


Multi-line Text Fields 

There are two ways to handle multi-line text fields in 
RALLY: 

• Using multi-line foim/repoit fields—limit of 512 char¬ 
acters 

• Using a callable editor—no limit on size 
Both methods are described below. 


Using Multi-line Form/Report Fields 

The easiest method is to define an Rdb text field that is 
large enough to hold multiple lines of text. Use any of the 
normal RALLY procedures for creating a form/report, and 
then change the vertical size of the field to be more than 
one line long. This means changing the end line so that it 
is greater than the start line. 

The length of fields in RALLY is restricted to 512 charac¬ 
ters or less, so this method is useful only for small amounts 
of text. 

If the field is to be used for entering or modifying the text, 
then you must edit the field’s input and validation options: 

Input options: 

• Lines horizontally scroll: clear 

• Up, down and newline can exit field: clear 
Validation options: 

• Newline characters not allowed: clear 
Automatic Word Wrapping 

RALLY provides a feature for automatic word wrapping. 
When this feature is enabled, the user can enter multi-line 
text without pressing RETURN to separate lines. RALLY 
will automatically insert a carriage return at the nearest 
word break each time that the text fills up the width of the 
field. 

Rather than turning word wrap on and leaving it on, we 
advise that you turn word wrapping on each time that you 
enter a multi-line field and off when you exit the field: 

• use ’set word_wrap’ when you enter field 

• use ’clear word__wrap’ when you exit field 
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Unfortunately these commands cannot be executed di¬ 
rectly from any of the foim/report action sites; they can, 
however, be executed from within macros and local func¬ 
tions. 

To make your application turn word wrap on and off auto¬ 
matically using macros, just define one macro to turn word 
wrapping on and one to turn it off, and then save them in 
a special macro file that is always used with the applica¬ 
tion. You can then invoke the macros from the action sites 
directly using the CALL CMD call type. 

To use a local function, write an ADL procedure that sets 
word wrap on or off depending on the state of a global 
variable. You must use the ADL aliases for the commands 
with the CALL_CMD function: 

IF turn_word__wrap__on THEN 

{ Set word__wrap } 

CALL__CMD (setpwrtype) ; 

ELSE 

{ Clear word_wrap } 

CALL_CMD(clrpwrtype); 

Use the Edit a Packet's Local Function Options form to 
make that procedure the local function for the form/report. 

Then define two more ADL procedures, one for the before 
field action and one for the after field action. Make the 
before action procedure set the global variable to indicate 
that word wrap should be turned on and then execute the 
local function: 

{ Set state variable } 
turn_word__wrap__on := 1; 

{ Use local function } 

CALL__CMD (frfunction) ; 

Make the after action procedure set the global variable 
to indicate that word wrap should be turned off and then 
execute the local function: 

{ Set state variable } 
turn__word__wrap_on : = 0; 

{ Use local function } 

CALL CMD(frfunction); 


With a Callable Editor 


If your application requires that pieces of text more than 
512 bytes long must be displayed, then you should use a 
callable text editor to display the text. Write 3GL code 
(e.g. BASIC, COBOL) that invokes a callable editor (e.g. 
TPU, EDT). Store file names in the database, instead of the 
text, and create RALLY external program links to invoke 
the 3GL code and pass the file name from the database to 
the program. 


One useful technique is to set up your application so that 
the user views the text by positioning to the record of in¬ 
terest, then using ’use local_function’. For example, you 
could have a directory style report that listed all of your em¬ 
ployees. To see the r£sum£ for any employee you would 
move your cursor to the employee and press GOLD-M. This 
would invoke the ’use localjunction’ command, which 
would invoke the external program link, which would in 
turn invoke the callable editor. Use the Edit a Packet's 
Local Function Options form to set the form/report’s local 
function to call the external link. 


Floating An Aggregate Field 

When you define a form/report aggregate in RALLY, you 
normally put the aggregate field on the output order for 
the parent group—one group higher than the group over 
which the aggregation will take place. This means that the 
aggregate field, and any text that you create for it, will 
be positioned relative to the parent group, not to the child 
group. If there will be a varying number of records in the 
child group, and you would like the aggregate to float up 
and down on the page, so that it always appears directly 
below the last child record, then you must use the ’’relative 
positioning” foim/report feature. For example, say that you 
wanted to make the following form/report: 


Sales by Salespeople 
Lew Lasher 


9-Jan-1988 

$ 

12.31 

Total 

$ 

12.31 

Tony Rogers 

3-Jan-1988 

$ 

47.43 

12-Jan-1988 

$ 

12.23 

23-Jan-1988 

$ 

8.76 

Total 

$ 

68.42 


You do this by putting the aggregate (the total) and its 
text area (for the word ’’Total” and the line above the total) 
within a format group, and positioning the format group 
relative to the end of the child group. You specify this on 
the Edit a Group's Display Options Relative to a Group 
form: 

Display below group: ORDERSGROUP 

You will usually want to mark the format group as not 
displayed on first and middle pages, so that it only appears 
once for each parent group, regardless of how many pages 
the child records for that child take. Make sure that you 
always leave room for the format group at the bottom of 
the form/report. 

When using relative positioning, be sure to clear the sub¬ 
form attribute when you create your format groups. The 
subform attribute is set by default when you create a for¬ 
mat group, but subfoims are used only to create pop-ups. 
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First/Middle/Last Formatting 


First/middle/last formatting is most often used to create 
header and trailer pages. It also gives you the ability to 
specify special formatting for the first page of data for a 
given parent, for middle pages, and for the last page. 

First/middle/last formatting can be applied to groups, 
fields and text areas. It is applied most often with format 
groups. 

Output Orders Are Significant 

In ordinary situations you need not be concerned about 
the order of objects on the output order for a group. In 
such cases you can think of the output order as an owner¬ 
ship list—a list of the objects owned by the group. How¬ 
ever, when using advanced formatting features such as 
first/middle/last formatting, you should make the output or¬ 
ders for all groups reflect the order that the objects will 
be displayed. For example, objects that will be displayed 
only on the first page of a report should always be before 
objects that will appear on middle pages, and objects that 
will appear only on the last page should always be at the 
end of their parent’s output orders. 

Image Editor State 

To help you forsee what your form/report is going to 
look like with real data, the Dialog provides you with the 
ability to tell the form/report image editor to display the 
form/report as it will look in different situations. For ex¬ 
ample, to see how the last page of data for a group will 
be formatted, use the Change a Group's Image Editor State 
form to select last page formatting for the group in question: 

Page location of group: LAST 

Leave the group name blank when you want to set the state 
for the main group. 

Similarly, when you set "start new page" for an object, 
then the logical page numbers for the object, and all of the 
objects that follow it in the form/report, are incremented by 
one. By default, you will always be shown logical page 1 
in the image editor. There is an example of how to view 
later pages below. 


Header and TVailer Pages 



Create the text area explicitly, rather than relying on the 
image editor to create it for you. Put the header page text 
area and any special header fields into the header format 
group just created. 


Set "start new page on first page" for the title text to be 
displayed on regular (middle) pages: 


Start new pac 
First page: 
Middle pages: 
Last page: 


Setting the "start new page" attribute for the title text on 
the data page is like inserting a form feed right in between 
the the header page and the data pages. The resulting page 
break makes the first instance of the data page the second 
page of the report, so to view it after making this change 
you must use the Change a Group's Image Editor State 
form to select page 2: 

Page number to display: _2 


Trailer Pages 


Create a format group and put it at the end of the main 
group’s output order. Clear the subform attribute for the 
format group, mark it as not displayed on first or middle 
pages, and set "start new page on last page": 


Do not display c 
First page: X 


Middle pages: X 
Last page: 



Create the text are for the trailer page text explicitly. Put 
the text, and any special trailer page fields into the trailer 
page format group. Because two page breaks occur before 
the trailer page is formatted, the trailer page is on logical 
page 3, so you must use the Change a Group's Image Editor 
State form to select page 3 in order to use the image editor 
to edit the trailer page: 

Page number to display: _3 


If the parent group is the main group, first, middle and 
last refer to the entire form/repoit—first page means the 
first page of the form/report, last page means the last page, 
and middle page means all the pages in between. 

Header Pages 

To create a header page for a form/report, create a format 
group and put it at the beginning of the main group’s out¬ 
put order. Clear the format group’s subform attribute, then 
maxk the it as not displayed on middle or last pages: 


The resulting form/report structure will be: 

Main Group 


+ - + - + 

I i I 

I I I 

Header Data Trailer 

Format Source Format 

Group Group Group 
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Using First/Middle/Last With Data Groups 

If an object is within a data group, first, middle, and last 
refer to the pages spanned by the current record of the 
parent data group. If an object has its attributes set so 
that it is not displayed on first and middle pages, and there 
are several pages worth of child group records for a given 
parent value, then the child object will not appear on the 
first page for the parent, or the middle pages, but only on 
the last page for that parent value. 

For example, above it was suggested that when the data 
for a group with a floating aggregates spans multiple pages, 
the floating aggregate should only appear on the last page. 
To implement this, the format group that contains the ag¬ 
gregate and its label should have the following attributes: 

Do not display on 
First pages X 
Middle pages: X 
Last page: 

Making First Pages Distinctive 

It is common for the child records for a given parent 
record to appear on more than one page. If you have re¬ 
ports where this happens, you may find it useful to use 
first/middle/last formatting to make it easy to tell the first 
page from the overflow pages. 

For example, you could create a special text area that is 
only displayed on first pages, and/or have a special text area 
that just says "Continued”, and have that only appear on 
middle and last pages. If this technique was applied to the 
form/report shown above, the first page with information 
about Lew Lasher might look like this: 


Lew Lasher 


23-Jan-1988 

$ 

47.43 

24-Jan-1988 

$ 

47.43 

25-Jan-1988 

$ 

47.43 

26-Jan-1988 

$ 

47.43 

27-Jan-1988 

$ 

47.43 


While the second page might look like this: 

Page 2 

Lew Lasher [Continued] 

28- Jan-1988 $ 47.43 

29- Jan-1988 $ 47.43 


Tony Rogers 

23-Jan-1988 $ 47.43 

26-Jan-1988 $ 47.43 

29-Jan-1988 $ 47.43 

To do this, explicitly create a text area for the bar and 
a text area for the "continued” message. As noted above, 
make the parent group’s output order reflect the order in 
which the child objects will be displayed. Put the first 
page text (the bar) at the beginning of the parent group’s 
output order, and the middle/last page text ("continued") at 
the end of the output order. 

Use the Edit a Text Area's Location on Page Options form 
to maik the first text area as not displayed on middle and 
last pages, and the second text area as not displayed on first 
pages. 

Use the Text Area to Edit form to explitly select the text 
areas whenever you to edit them. This will keep the image 
editor from getting these text areas confused with other text 
areas in the form/report. 


DTR-12 






Graphics 
Application 
Special Interest 
Group 



Newsletter 


Table of contents 


Submissions ...GAP-1 

From the editor ...GAP-1 

Woods meeting minutes .GAP-2 


Submissions 


Articles, copies of viewgraphs, tips and tricks, and graphics output are all welcome submissions for 
the Graphics Applications Special Interest Group (GAPSIG) newsletter. There are many ways to make 
submissions: 

1) Send in a tape. Tapes can be 1600 or 6250 BPI density; VMSBACKUP or RSX BRU formats 
are acceptable. Your editor uses the Mass-11 word processing system from Microsystems 
Engineering Corporation, so submissions in this format are okay. Otherwise, provide straight 
ASCII documents. Please place any charts into a separate file. And, please enclose a letter 
with your address and any notes and description for format that you desire. 

2) Send in paper. Hey, your editor can type and chew gum at the same time, so don’t be afraid 
to send in hard-copy. And, if all you have is notes, FINE! Send them in!!! We have many 
folks who can take the ideas and flesh them out with English language extensions. Questions 
are desirable, too; DECUS should, in the opinion of your humble editor, be a place to trade 
information, so questions count for as much as answers here. 

3) Mail to HAYS on DCS. If you have a DCS account and the article is all textual, mail it to 
HAYS on the DCS system. 

Your editor’s address appears in the From the editor section, so mail yours in today! 


From the editor 


Bob Hays 
KMS Fusion, Inc, 

3621 South State Rd. 

Ann Arbor, MI 48106 

This is a sparse issue of the newsletter for many reasons, including the upcoming Symposium (the 
newsletter is prepared two months before the issue date on the cover, so this is being done in April) and 
new plans growing from the GAPSIG Woods Meeting in March. I personally found the meeting really 
helpful thanks to many ideas forthcoming from all the attendees. Combined with the newsletter survey, 
there has been much new thinking in my cubbyhole. 

Most obvious is the changeover to two-up format, or landscape mode printing much like other SIG 
newsletters. While some newsletter survey replys disliked landscape format, more wanted a unified look- 
and-feel (hope another computer vendor isn’t taking a bite out of this issue). 

I’d like to try some new things out which were discussed by the SIG steering committee. First, 
let’s try a "Graphic-of-the-Month". For this, submit any single black and white graphic image that 
conveys a useful idea and was created on a DEC-based system or with the help of a DEC-based product. 






Include a short (100 or less word) description of: how the image was manipulated and generated, what 
equipment was used, any neat portions of algorithms applied, etc. 

Which leads in to another desired end result: I want more graphics in the Graphics Applications 
SIG newsletter! Please, include final-quality plots, graphs, images, etc. for articles if you have time. I 
know people are doing really fun and useful things graphical today, so let's see it. 

I plan to provide a three-year index every year in a newsletter issue. Which issue is up-in-the-air, 
since it depends on page counts and other mundane things. However, many members (myself included) 
have always wanted to find that certain article. The initial index will be by subject and possibly, space 
permitting, by title. 

We want your ideas for a new logo! GAPSIG has lacked a spiffy, modern logo for quite long 
enough. Submissions for this also should be addressed to me at the above address, and should be in 
hard-copy form. 

I’ve blow on long enough for this issue. Suffice it to say that there are new plans and additions to 
your GAPSIG newsletter planned over the next year! 


Woods meeting minutes 


Mike York 


The DECUS GAPSIG Steering Committee woods meeting was held in Phoenix, Arizona, March 26 
and 27. Those attending were: 


Bob Goldstein 
Bob Hays 
Rick Landau 
Mike McPherson 
Bijoy Misra 
Jim Sims 
Henry Schneiker 
Paul Waterstraat 
Mike York 


Image processing working Group Coordinator 

Newsletter Editor 

Counterpart 

Library, Vice Chair 

SIG Chair 

Engineering Working Group Coordinator 
Hardcopy Working Group 
Standards Coordinator 
Member at Large 


The woods meeting began the morning of March 26 with a review of the Anaheim Symposium. 
Overall, the Steering Committee members had quite favorable reactions to how the GAPSIG performed at 
Anaheim, but a few problems were brought up: cancelled sessions were more of a problem than usual 
since some speakers couldn’t make the symposium due to budgetary considerations and some sessions 
were scheduled by someone other than the intended speaker, with the actual speaker being notified too 
close to the symposium to adequately prepare. 


The campground was another concern; security issues and the lack of traffic through the 
campground were noted. It was suggested that more announcements about the campground be included 
in symposia sessions at future symposia. 


There was also some discussion about session notes. It was pointed out that Digital is submitting 
much more material for the session notes, but many other speakers are failing to submit material. It was 
explained that many presenters prepare for sessions in the two weeks before symposia, long after the 
deadline for session note submissions. There was some discussion about the GAPSIG publishing its own 
session notes, but that idea was abandoned when it was revealed that the session notes could not then be 
pre-sold. It was then suggested that the GAPSIG could publish an addendum to the session notes, to 
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include materials submitted after the deadline. It was finally decided to have Steering Committee 
members and other volunteers gently remind scheduled session speakers of the deadline for session note 
submittals. 

Members of the Steering Committee then gave brief reports on their functional areas. Henry 
Schneiker, coordinator for the hardcopy working group, reported that he has not yet been able to 
schedule a meeting with Digital concerning hardcopy futures, but would work on scheduling the meeting 
within the next few months. 

Mike McPherson, Library Coordinator, reported that a Library Committee meeting was recently 
held in Washington. D.C. Mike reported that the meeting had a good representation of SIGS and was 
well organized. Discussed at the meeting were catalog restructuring, indexing the catalog, and electronic 
distribution of library programs. 

Bob Hays, Newsletter Editor, was next. Bob reported that a survey of newsletter readers had been 
conducted. The survey results indicate that readers: 

- want more technical articles 

- want more how to articles 

- don’t like landscape orientation 

- want common format for newsletters 

- want an index 

- want reviews of library programs 

- want articles rated by expertise 

- want a list of current versions of products 

Bob then went on to briefly discuss other newsletter issues, such as electronic submission of articles, 
color in the newsletters, and a graphic of the month feature. 

There was then some discussion about using the newsletter for publishing symposia information. 
The general consensus of the Steering Committee was that the lead time for publishing the newsletters 
was too long to be useful for symposia information. Some other forms of communication were then 
briefly discussed, such as bulletin boards & networks, a special GAPSIG publication, and LUG chair 
mailings. 

Paul Waterstraat, the new Standards Coordinator, discussed the turnover from the old standards 
coordinator, Jim Flatten. Paul reported that there are three ANSI meetings a year, which prompted some 
discussion about budgeting for attending the meetings. There was then some discussion about the 
GAPSIG sponsoring a simple "standard" graphics application that could be written using various 
standards and used as a basis for comparison of standards. 

A general discussion about third party involvement in the GAPSIG followed. The SIG has 
historically had a great deal of third party involvement, because Digital had few serious graphics products 
until a few years ago. However, with the emergence of workstations and laser printers. Digital is now in 
the mainstream of graphics products. Should the SIG actively solicit third party involvement? The 
consensus of the Steering was yes, but commercialism guidelines will have to be adhered to. 

A brief discussion about the technical content of symposia sessions followed, with the general 
opinion of the Steering Committee being that over all, the technical content of symposia sessions has gone 
down, but the GAPSIG sessions have retained their technical content. 

The rest of the day, and one hour the following morning, was spent on each Steering Committee 
member giving a short presentation on the particular applications they are involved with. While the 
content of these presentations is too much to publish in these minutes, it was apparent that there is a 
tremendous amount of experience and expertise on the Steering Committee, and it was very interesting to 
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see what the other Steering Committee members are involved in. The presentations were very well 
received by the Steering Committee. 

A good portion of the second day was spent revisiting a problem the SIG has been dealing with for 
some time: should the SIG expand its scope to include more activities pertaining to workstations, even if 
some of these activities may not directly relate graphics? This question was brought up after some 
complaints were received in Nashville about a lack of support for workstations is DECUS. After a great 
deal of conversation, the Steering Committee reached a consensus that the GAPSIG is supporting 
workstations within the scope of its charter, and to expand its scope would not be a good idea. 

The next item of business was some discussion about a questionaire to be distributed to the 
GAPSIG membership. It was decided that the questionaire will be one sheet of paper, and will probably 
be distributed at symposia, published in the newsletter, and a random mailing to GAPSIG members. 

The last item of business was assigning tasks for the upcoming symposium. Bob Hays will be the 
session chair coordinator, Mike McPherson will be the campground coordinator, and Henry Schneiker 
will be the on-site coordinator. 
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FROM THE 

EDITOR'S KEYBOARD 


IN THIS ISSUE 


The following editorial is solely 
the opinion of the author, and does not 
represent the views of DECUS or of 
Digital Equipment Corp. Responses to the 
Editor's remarks are heartily welcomed. 

I don't know what to do, it's almost 
deadline, and we have no hardware 
problems to report. (The roof is still 
leaking, but not over the printer room 
or my office, it's the conference room 
this month!) 

Just to keep things lively, Milt 
Campbell has replied to a previous 
editorial where I stated, "I don't think 
it would cost the RT11 group much to 
provide a fully commented distribution 
on a suitable media as an extra cost 
option." Turns out your editor didn't 
know beans about the mechanism of RT11 
distribution. Milt informed me that if 
you purchase the RT11 source license and 
distribution, you get just that, Fully 
commented sources. (Just what I asked 
for.) My apologies to the RT11 
developers and to Milt. 

As you may have noticed, (if you 
read the front of the May issue,) your 
editor has agreed to accept an even more 
involved role with the SIG's 
Newsletters. Since I stepped into Bill 
Leroy's shoes at the worst possible 
time, (I had to wrestle with Budget, 
work out the bugs on a new set of 
operating proceedures, and prepare for 
Spring DECUS) the DeVIAS letter has 
taken a back seat for a time. Be advised 
that the Letter is my first love, and it 
will NOT suffer greatly as a result of 


Your editor has finally caught up 
with things, and has included in this 
issue a talk from the fall Symposium on 
the IAS product panel by Jack Lockhart 
of DEC, manager of the mature software 
products group. If you really want to 
help Jack direct the efforts of the IAS 
maintenance crew, any feed-back from 
readers would be greatly appreciated. 


CONTRIBUTION 

GUIDLINES 


Contributions of articles, SPR's, 
letters, etc. will be accepted in any 
form, (including notes jotted on stained 
tablecloths.) They will be more happily 
accepted in the following formats: 

Paper submissions will always be 
accepted. Publishing may be delayed 
until the editor gets some time at the 
keyboard to convert them to our current 
format. We can accept submissions by 
FAX. 

Contributions may be submitted on 
tape, (800,1600, 3200 or 6250 BPI,) DEC- 
tape II, and DecMate or RT11 floppies. 
We're not fussy, we'll even accept paper 
tape or cards. We can read any IAS/RSX, 
RT11, VMS format. Any media sent to us 
will be promptly returned. 


We have 2400/1200 baud modems on our 
IAS system and our VAX, with KERMIT for 
electronic submission. Give the editor a 
call @ (312)-791-8075 (preferably later 
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in the day,) to obtain access info, etc. 

If you have a problem you would like 
to submit to the Devias Demon, send it 
to the Editor at the following address. 
Answers to problems from members (or 
anyone) should also be sent to the 
Editor. 

Frank R. Borger 
Michael Reese Medical Center 
Department of Radiation Therapy 
Lake Shore Drive at 31st St 
Chicago, IL 60616 


TEN YEARS 
AGO THIS MONTH 


A report on the DECUS Spring 
Symposium mentioned the DEC announcement 
of "TRAX, a totally new operating system 
for transaction processing. This system 
is similar in function to IBM CISC-type 
systems. All screen formatting, error 
recovery, journaling, transaction 
queuing, etc. is handled by TRAX. All 
the user has to do is write the 
application code in either BASIC PLUS- 2 
or COBOL." (Oh where oh where has my 
little Trax gone? ed.) 

DEC also anounced the "ONE PRODUCT 
STRATEGY" whereby RSX-11D and IAS would 
be combined into one integrated system. 
IAS 3.0 is planned for release in late 
1978 or early 1979. 

The issue also contained an early 
release of "Files-11 QIO notes" an 
article by Ralph Stammerjohn (updated by 
Mike Blake-Knox.) For users who wanted 
direct QIO access to the Files- 11 disk 
structure, it was the first light on a 
subject never properly documented by 
DEC. 

And finally Glen Everhart announced 
in a letter the availability of the 
latest RSX11M-RSX11D-IAS version of 
FOCAL! 


IAS PRODUCT PANEL 


Jack Lockhart, Manager 
Mature Sorftware Products Group 
Digital Equipment Corporation 


There is an ongoing Digital 
committment to IAS. 

Most of the user community today is 
in 2 or 3 different sections. There is 
a strong contingent in the intelligence 
agency, who typically does not come to 
DECUS, there is a commercial segment, 
and a couple of spin-offs in the 
newspaper field. Over the last couple 
of years, Digital's efforts toward IAS 
have grown, and further growth is 
expected over the next couple of years. 

We are also beginning to do a better 
job of field support for IAS. As the 
community grows, and most of the growth 
is in the government area, that 
increases our ability to provide support 
for the entire community. 

Digital's basic Engineering goals as 
reguards IAS are as follows: 

Increase reliability. 

Increase support responsiveness. 

We believe we have done a lot to 
increase the reliability of the product, 
but we still have a ways to go to 
improve support. At present we have a 
backlog of approximately 20 SPR's. The 
developers are holding their own, last 
month the number of resolved SPR's 
equaled the number of new SPR's. Update 
D is now in field test, and we are 
generating internal SPR's and getting 
problem reports, (QAR's) from the field. 
Once that these are resolved, we hope to 
get the backlog of SPRs down. 

Telephone support service. 

There is telephone support for IAS. 
That is one area we have target that 
needs some improvment in the way that we 
organize that support. 

Improved predictability. 

It's still not predictable when 
releases of updates occur. Essentially 
we have a five man engineering 
organization that covers a lot besides 
IAS. IAS is a full blown operating 
system with a lot of complexity to it. 
We must not only maintain the operating 
system, but all the layered products. It 
takes a lot of work to keep up with it. 
The end result is that we are not as 
predictable as we would like. We are 
always looking for information from the 
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user community to help us prioritize our 
efforts. What new features should be 
added, what is valuable to you and what 
is not valuable to you, what we should 
not be wasting our time on. 

Update D 

Update D has been in field test 
since September. There are a number of 
problems that have been found with 
layered products and have been resolved. 
We have a tentative date of closing 
field testing in January or February. If 
we feel we need more testing before we 
put the product out we may extend field 
test. (Editor's note, field test was 
finished in January.) 

Some of the functionality that you 
probably will be interested in in update 
D include: 

o DUMU, which is a multi-user MSCP 
handler which supports Digital 
Storage Architecture devices. It 
will help you with some through¬ 
put issues and conserve system 
resources. 

o Crash support has been extended 
to non-tape devices. 

o RMS version 2 is now supported. 

It provides disk overlay RMS. It 
does NOT support Supervisor mode 
libraries, and does not support 
clustered libraries. 

o Sort Version 3.0 is supported. 

o There are some improvements to 
the task builder, mainly dealing 
with Autoload vector handling. 

o Datatrieve 3.0 is supported. 

o Fortran 5.0 is supported. 

o Macro 5.5 is supported. 

o VT3xx terminals are supported. 

o A number of bug fixes are done. 

We also provide a limited amount of 
strategic consulting to what we consider 
strategic accounts, which allows access 
to internal engineering resources. 
Essentially this has to be pre-arranged, 
via an agreement between the account and 
Digital, that they want to take 
advantage of this kind of service. There 


are some times and some commitments that 
Digital makes, and there is a pre^ 
arranged escalation criteria and some 
commitments of what kind of services 
Digital can provide and what level of 
services. 

Question and Answer 

Question: On your DUMU handler. In the 
past, DEC hasn't supported multi -user 
disk handlers. Is this going to be a 
complete support? For example, can you 
do a sysgen etcetera on disks connected 
to the second controller? 

Answer: I don't know. Give Nancy Fay 
Autenzio, the product manager for IAS a 
call, and she can get the specific 
technical information to you. 

Question: Your slide showed support for 
Fortran version 5.0. I note that on the 
M and M+ side, version 5.2 is already 
out in the field. Is support limited to 
5.0? 

Answer: As far as I know, support is 
limited to version 5.0. 

For the layered products, often 
times there is nothing significantly 
done to the layered products. After you 
build the new operating system, you test 
the layered products underneath it. Just 
because it works under C may or may not 
mean that it works under D. Whatever the 
current version of the layered product 
is at the time it was tested determines 
what version of the layered product has 
been validated, and as far as we know, 
works correctly. In some cases that 
means that some work was done, probably 
to the operating system, to make that 
happen. In some cases little of 
anything was done. It is a statement of 
validation rather than a statement that 
any changes were made to the operating 
system. 

Question: Does DEC have any intention of 
supporting C under IAS? 

Answer: No. 

Question: Does DEC have any intention of 
supporting Ethernet under IAS, (for 
example DECNET phase IV?) 

Answer: There is no intention of 
supporting DECNET phase IV under IAS. 
In fact, as you know there has been 
considerable concern about DECNET-IAS 
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altogether. It currently only supports 
Phase III, it really in the SPD only 
allows you to talk to other IAS systems. 
VMS is going to be going to phase V, the 
other PDP11 operating systems are or 
will be going to phase IV, IAS DECNET 
will probably be facing retirement 
before too long. 

Question: So there is no intention of 
supporting Ethernet in any fashion? 

Answer: There is no intention of 

supporting it through IAS decnet. 


THE PROGRAM OF 
THE MONTH CLUB 


One of the things wrong with hard 
copy documentation of short BASIC 
programs, indirect command files, etc is 
that with no compiler there is no nicely 
paginated output, no date/time stamp, 
and no indication of disk and uic. 

This program produces a paginated 
output listing, along with a 
specification of Date/time disk and UIC. 


Note that the header line should be 
customized with the local organization's 
name, etc. It is designed for 132- 
character output, but output to 80- 
character devices will still have all 
the relavent header information. 

.title pag 
.ident /mrhOOl/ 

.mcall finit$,fsrsz$,qiow$,dir$,call,return 
.mcall open$w,open$,open$r,get$,put$,close$ 

.mcall csi$,csi$l,csi$2,csi$sw,gmcr$,exit$s,gtim$ 

.mcall gcml$,rcml$,gcmlb$,print$,csi$nd 
.mcall fdbdf$,fdat$a,fdrc$a,fdop$a,fdbf$a 
.mcall fdop$r,nmblk$ 


pag paginate listing program 

provides listings of programs etc on a paginated basis 
header lines contain device, uic name etc and date time 
listing a max of 55 lines/page so dont print over fold 

calling sequence 

mcr>pag[elist] dev:[uicjname.type 

optional switch "/ta" puts leading tab in for 
use with lpl so can punch and put in ring binder 


mcr>pag[elist] dev:[uicjname.typ=dev:[uicjname.typ 

if no output file spec is given, the output defaults to: sy:name.lst 
and the file is automatically spooled to lp: 


; evf's 

and luns 

5 

outlun 

=i 

;output file lun 

outevf 

=i 

;and evf 

tilun 

=2 

;terminal io lun 

tievf 

=2 

;and evf 

tiflun 

=3 

;terminal "file" lun 

tifevf 

=3 

;and evf 

influn 

=4 

;the first in-file lun 

infevf 

=4 

;and evf 


.sbttl 

main line code 

start: 

finit$ 

;set up 


jsr 

pc,.rdfui ;get ui 
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5$: 


6 $: 


7$: 


22 $: 


4$: 


44$: 


441$: 


442$: 


444$: 


222 $: 


mov 

gcml$ 

cmpb 

bne 

exit$s 

tstb 

bpl 

dir$ 

dir$ 

exit$s 

mov 

mov 

mov 

csi$l 

csi$2 

bitb 

bne 

clr 

csi$2 

bitb 

beq 

mov 

mov 

jsr 

bitb 

bne 

dir$ 

dir$ 

exit$s 

fdop$r 

open$r 

bcc 

dir$ 

dir$ 

exit$s 

mov 

mov 

mov 

cmpb 

beq 

sob 

movb 

movb 

movb 

mov 

mov 

mov 

movb 

sob 

tst 

beq 

csi$2 

bitb 

beq 

mov 

mov 

jsr 

bitb 

bne 

mov 


rl,uic {save the uic (binary) 

#gcblk {get the command line 

#ge.eof,gcblk+g.err ;end of file on command input ? 

5$ ;no 


;yes, quit 

gcblk+g.err ;any other errors ? 

6$ ;no 

#erpri ;report command line file error 

#cmderr 


#1,inpflg ;set flag that input file spec seen 

;fill in pointers in csi block 
gcblk+g.cmld+2,csblk+c.cmld+2 
gcblk+g.cmld,csblk+c.cmld 
#csblk ;and parse it 

#csblk,input,#switch 5 try for an input spec 
#cs.nmf,c.stat(rO) ;was input spec'd 
7$ ;br if it was 

inpflg ;else clear flag that says it was 

#csblk,output {default to file spec to be spooled 

tcs.dif,c.stat(rO) ;did they spec a uic ? 

22$ ;no 

#csblk+c.dird,r2 ;yes point to descriptor 
#uic,r3 {place to store it 

pc,.ascpp ;convert string to octal number 

ttcs.nmf,c.stat(rO) {is a name given? 

4$ ;yes 

#erpri 

#namerr 


#infdb,,#csblk+c.dsds ;fill in file name to be listed 

#infdb ;and open it 

44$ ;br if ok 

#erpri ;else report problem 

#namerr 


csblk+c.dsds+10,rl 
rl,namlen 

csblk+c.dsds+12,r2 
(r2)+,#'. 

442$ 
rl,441$ 

#'1,(r2)+ 

#'s,(r2)+ 

#'t,(r2)+ 

namlen,rl 

csblk+c.dsds+12,r2 

#namsav,r3 

(r2)+,(r3)+ 

r1,444$ 

inpflg 

333$ 

#csblk,output 
ttcs.dif,c.stat(rO) 
222 $ 

#csblk+c.dird,r2 
#uic,r3 
pc,.ascpp 

#cs.nmf,c.s tat(rO) 
333$ 

namlen,rl 


;change output file type to "1st 
;get length of name string 
;save length 
;and start 

;found the in the file name 
;yes 

;no, get another 

;had to have so assume ok 

;overwrite "typ" with "1st" 


;get length again 
;and start 
;point to save area 
;save name string 

;was there an input file spec 
;if not, default to name.1st 
;get output file name 
;did they spec a uic ? 

;no 

;yes point to descriptor 
;place to store it 
{convert string to octal number 
;is a name given? 

{branch if name ok 
;get length again 
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244$: 

333$: 


mov csblk+c.dsds+12,r2 

mov #namsav,r3 

movb (r3)+,(r2)+ 

sob rl,244$ 

fdop$r #outfdb,,#csblk+c.dsds 

open$w #outfdb 

bcc 2$ 

dir$ #erpri 

dir$ Ifilerr 

jmp die 


;point to csi block 
;point to save area 
{restore name string 

;fill in filename of output file 

;and open it 

;br if open went 

;tell him file problems 

;and close input, then exit 


2 $: 


rego: 


11 $: 


.sbttl transfer to listing file 


12 $: 


in: 


333$: 


335$: 

336$: 


dir$ 

mov 

movb 

mov 

mov 

tst 

beq 

mov 

mov 

jsr 

mov 

mov 

jsr 

sub 

mov 

put$ 

mov 

mov 

tst 

beq 

mov 

mov 

jsr 

mov 

mov 

jsr 

mov 

mov 

jsr 

sub 

clr 

mov 

put$ 

get$ 

cmpb 

beq 

tst 

bpl 

dir$ 

dir$ 

jmp 

mov 

add 

tst 

beq 

put$ 

br 

put$ 

bcc 

dir$ 


#gettim 

#l,page 


infdb+f.fnb+n.unit,devnum {fill in device unit number in block 


#edblk,rO 
#hdrmeO,rl 
tabflg 
11 $ 

#hdrmea,rl 
#hdrbf0,r2 
pc,$edmsg 
#hdrmel,rl 
#page,r2;address 
pc,$edmsg 
fredblk,rO 
rO,outfdb+f.nrbd 
ttoutfdb,#edblk 
#edblk,rO 
#edmesO,rl 
tabflg 
12 $ 

#edmesa,rl 

ledbuf,r2 

pc,$edmsg 

#edmesl,rl 

#edbuf1,r2 

pc,$edmsg 

#edmes2,rl 

#edbuf2,r2 

pc,$edmsg 

#edblk,rO 

r5 

rO,outfdb+f.nrbd 
#outfdb,ttedblk 


get date and time 
set page # to 1 


set for edmsg 
address of input line 
want leading tab ? 
br if not 

else change format 

address of buffer 

fill in name 

address of buffer 

of buffer 

fill in page # 

get length of xfer 

;tell sys length 

put the first header line 

address of output buffer 

address of input line 

want leading tab ? 

no 

change input line 
address of data buffer 
do device and uic 
point to 2nd decode line 
and 2nd data buffer 
do name.type;version 
point to last decode line 
and last data buffer 
and do date, time, page t 
sub start of resultant header line 
clear lines/page counter 
;set length of variable line 
put out variable header line 


#infdb,#bufl,#132. {get a record 
infdb+f.err,#ie.eof ;end of file 
done ;yes 

infdb+f.err ;no 

333$ ;if plus ok 

#erpri 
#filerr 

done ;and exit 

infdb+f.nrbd,outfdb+f.nrbd {transfer size of line 
tabflg,outfdb+f.nrbd {adjust for leading tab 
tabflg 
335$ 

#outfdb,#bufO 


336$ 

#outfdb,#buf1 
334$ 

#erpri 


;is there leading tab 
; no 
;yes 


;and put the record 
;br if ok 
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dir$ 

ttfilerr 



jmp 

done 

;and exit 

334$: 

inc 

r5 

;count a line 


cmp 

r5,#54. 

;near end of page ? 


bit 

in 

;no, just do next line 


clr 

r5 

5 yes, clear counter 


inc 

page 

;inc page number for printout 


jn>P 

rego 

;print header line again 

done: 



;normal exit 


tst 

inpflg 

;spool the output ? 


bne 

1$ 

;not if two files were specified 


print$ 

#outfdb 

;spool the file to lp 


br 

die 

;and quit 

1$: 

close$ 

#outfdb 

;close the output file if not spooled 

die: 

close$ 

#infdb 

;close input file 


exit$s 


;and exit 


.sbttl 

fdb's 



.sbttl 

input 

fdb 

5 

infdb: 

fdbdf$ 


; define fdb block 


fdat$a 

r.var,fd.cr 

;file attributes 


fdrc$a 

,buf1,132. 

;record 


fdop$a 

influn 

;file name 


fdbf$a 

infevf 

;evf 

9 

.sbttl 

output fdb 

1 

outfdb: 

fdbdf$ 


;define fdb block 


fdat$a 

r.var,fd.cr 

;file attributes 


fdrc$a 

,bufl,132. 

;record 


fdop$a 

outlun 

;file name 


fdbf$a 

outevf 

;evf 

9 

.sbttl 

terminal fdb 

tifdb: 

fdbdf$ 


jdefine fdb block 


fdat$a 

r.var,fd.cr 

;files attributes 


fdrc$a 

,bufl,80. 

;record 


fdop$a 

tiflun,tidsds 

;file name 


fdbf$a 

tifevf 

;file evf 

9 

tidsds: 

• word 

lti,ti 



.word 

0,0 



.word 

0,0 


ti: 

.ascii 

/ti:/ 


lti=.-ti 




• even 




.sbttl 

error 

messages 

9 

erpri: 

qiow$ 

io.wvb,tilun, 

tievf,,,,<primes,prilen,44> 

primes: 

.ascii 

/***PAG - / 


prilen= 

.-primes 




.even 



namerr: 

qiow$ 

io.wvb,tilun, 

tievf,,,,<nammes,naming,53> 

nammes: 

.ascii 

/Bad file name***/ 

namlng= 

. -nammes 




. even 



filerr: 

qiow$ 

io.wvb,tilun, 

tievf,,,,<filmes,fillen,53> 

filmes: 

.ascii 

/Error on file io***/ 

fillen= 

.-filmes 




.even 
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cmderr: qiow$ io.wvb,tilun,tievf,,,,<cmdmes,cmdlen,53> 
cmdmes: .ascii /Error on indirect command file***/ 
c.mdlen=. -cmdmes 


. even 



.sbttl 

miscellaneous 


•sbttl 

csi control block 

csi$ 



csblk: .blkb 

c.size 


. even 



5 

•sbttl 

gcml control block 

> 

gclun =tilun 



gcblk: gcmlb$ 

• 

2,rnp,,gclun 


> 

.sbttl 

switch 

table 

5 

switch: csi$sw 

ta,2,tabflg 

;specify switch itself 

csi$nd 



.sbttl 

other 

things 

> 

tabflg: .word 

0 

;flag to put in leading tab 

edlen: .word 

0 

;length of header line 

gettim: gtim$ 

edbuf2 

;get time in 2nd edmsg buffer 

bufO: .byte 

0,11 

;leading tab 

bufl: .blkw 

132. 

;the record buffer 

fsrsz$ 

3 

;make room for file storage 

.sbttl 

edmsg data 


hdrmeO: .ascii 

/%F%NMichael 

Reese Medical Center - - - 

.asciz 

/Department of 

Medical Physics Computer%25S%X/ 

.even 



hdrmea: .ascii 

/%F%N%8SMichael Reese Medical Center - - 

.asciz 

/Department of 

Medical Physics Computer%25S%X/ 

.even 



hdrbfO=infdb+f. 

fnb+n.fnam 


hdrmel: .asciz 

/ Page %D/ 


.even 



edmesO: .ascii 

/%NListing of 

%2A%M:/ ;device and number 

.asciz 

/[%B,%B]/ 

;uic 

.even 



edmesa: .ascii 

/%N%8SListing 

of %2A%M:/;device and number 

.asciz 

/[%B,%B]/ 

;uic 

.even 



edbuf: .word 

infdb+f.fnb+n. 

dvnm ;device string 

devnum: .word 

0 

;device number 

.word 

guic 

;group uic 

.word 

muic 

;member uic 

5 

uic: 


;start code stores uic here 

muic: .byte 

0 

;save member uic here 

guic: .byte 

0 

;save group uic 

* 

;storage for file name for output 

inpflg: .word 

0 

;flag for input file specified 

namlen: .word 

0 

;length of string 

namsav: .blkb 

40. 

{buffer to store string 

5 

edmesl: .asciz 

/%X£4S/ 

;name,type version 
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;point him to input fdb 


.even 

edbufl=infdb+f.fnb+n.fnam 
5 

edmes2: .asciz /on %Y at %3Z Page %D%2N/ ;date,time page # 

. even 

edbuf2: .blkw 6 ;room for date and time 

page: .blkw 2 ;do time, then set page # to whatever 

5 

;now the output buffer 

9 

edblk: .blkb 150. ;one line of output 

.end start 


1 

; Task build command file for the PAGinate program 

PAG/-FP/MU=PAG 

/ 

TASK=... PAG 
ASG=TI:2:3 
ACTFIL=3 
// 
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Happy Campers! 

Welcome to Camp DECUS. This issue of NETWORDS contains two noteworthy items: 

First, the announcement of Networks and Communications SIG Wishlist, coordinated by L. Stuart Vance. 
Cincinnati campers might wish to have your ideas for improvements or new product suggestions sent to 
"the right people"; here’s the vehicle. 

Second, a very informative article provided by the Digital Technical Journal, on the conception, birth and 
evolution of the LAT protocol, used in connecting terminals to hosts on an Ethernet. Digital’s Terminal 
Server products (The Ethernet Terminal Server, and DECservers ) use this protocol. The authors are 
intimately involved in the development of this protocol; their biographies (as of September 1986) follow the 
article. 

The week of DECUS "camp" will go by fast; so don’t try and digest everything at once. And don’t forget 
to write home! 

Judi Mandl 

Network SIG Newsletter Editor 
University of Connecticut Health Center 
263 Farmington Ave. 

Farmington, Connecticut 06032 

Networks and Communications SIG Wishlist 

Ever thought that LAN Bridge 100’s should be password protected from unauthorized use of RBMS? Or 
that DEC’s router product line should be improved to handle multiple T1 line cards? Or even that DEC 
should establish a "Network Advisor" expert system accessible by a toll-free number to aid in the diagnosis 
of network problems? If you have a suggestion for how DEC might improve an existing product, or have 
an idea for a new product or service that DEC might provide, then be sure to stop by the Networks and 
Communications SIG suite and fill out a Networking Improvement Request (NIR). After a number of 
NIR’s have been gathered, a summary of the suggestions will be published in a SIGs Newsletter issue, and 
circulated among LUG’s, where DECUS members will be given the opportunity to prioritize the list before 
presentation to DEC. 

If you have a suggestion, from product specific to visionary, please stop by and let us know! 

L. STUART VANCE 

Network SIG Wishlist Coordinator 

UT System OTS 

BRC / CMS 1.156A 

10100 Burnet Road 

Austin, Texas 78758-4497 

(512) 471-2416 

Digital Technical Journal, No. 3 September 1986 

(The Networks SIG Newsletter Condensed Version) 

TERMINAL SERVERS ON ETHERNET LOCAL AREA NETWORKS 

Bruce E. Mann 
Colin Strutt 
Mark F. Kempf 

Digital’s terminal servers provide flexible, cost-effective connections between terminals and host systems 
in a local area network (LAN). The product developers tried several approaches before developing the Local 
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Area Transport (LAT) protocol as the basis for all terminal servers. The LAT architecture supports connec¬ 
tions to multiple hosts over a high-bandwidth Ethernet LAN. LAT establishes a single virtual circuit 
between a terminal server and each host, and individual sessions are multiplexed over a virtual circuit. A 
unique directory service permits terminal servers to be configured automatically, learning about hosts as 
they become available. The latest implementations support mixed-vendor environments and Digital’s major 
operating systems. 

The Original Problem 

In 1981, Digital faced the task of designing a method for connecting a few hundred "dumb" terminals and 
printers to a VAXcluster system. If, as in the past, the terminal were connected to a single computer, then 
many of the advantages of clustering would be negated. Instead, it was proposed that terminals be 
connected to a "front-end" terminal server shared by all members of the cluster. This front end would then 
allow more flexible connections. A user terminal, for example, could connect to any processor in the 
VAXcluster group, rather than directly connecting to just one. Our goal was to migrate our existing 
installed terminal base gracefully from single-processor attachments to VAXcluster systems. 

The original effort to provide this server was called the CI-Mercury project by our development groups. We 
aimed to attach this terminal server directly to the high-speed cluster inter-connect, called the Cl, so that 
the server functioned as a switch. However, the cost of this scheme proved to be excessive. (The cost for 
the interface to the Cl itself was about $20,000.) Moreover, a connection to the Cl would have resulted in 
a server that could connect only to nodes in a single cluster. 

We also studied other vendors’ switch offerings as front-end terminal switches. These products function 
much as do the data-switch products available today; that is, backplane multiplexers on the CPUs are 
switched to the terminals. The problems with this approach were excessive cost, the lack of Digital 
technology in this product area, and poor availability. 

Because of these complexity and cost factors, the original CI-Mercury project was replaced with one called 
Pluto. This product envisioned using an Ethernet as the interconnect, thus lowering the attachment cost 
dramatically. This server was based on a PDP-11 central processor,and we chose a variant of the RSX-11S 
operating system for the initial kernel software. The lower-layer communications protocols used between 
Pluto and the VAXcluster nodes were the DECnet protocols, successfully used in other products. 

We believed that Pluto could be cost effective in large installations; however, its initial cost was too high to 
be competitive in smaller configurations. This cost factor was especially important as Ethernet became an 
integral part of Digital’s strategy. With Ethernet, it became practical and cost effective to distribute small 
terminal servers throughout an office environment rather than concentrating all terminal interfaces in a 
large, centrally located server. Therefore, in late 1981, work began on an eight-line terminal server, the 
primary goals being low cost and high performance. Internally, their project was dubbed Pluto Junior, later 
called Poseidon. 

Late in 1983, significant problems were encountered in the design of the Pluto and Poseidon terminal 
servers. The CTERM protocol, a new design of a layered DECnet protocol off-loading character-processing 
overhead from the host to the terminal server, proved to be more complex than anticipated. Measurements 
of message-processing overhead and estimates of the overhead in the DECnet/VAX software showed that 
CPU consumption in the host system would be a problem for keystroke editors. Existing studies showed 
that terminals were used in keystroke modes, rather than command-line modes, more than fifty percent of 
the time. Moreover, the Pluto server itself was experiencing severe performance problems. For example, 
CPU saturation occurred when running less than six terminals at 9600 baud, even when their terminal 
interfaces used direct memory access (DMA). 

Finally, a number of issues, not considered during the requirements phase, became more apparent: 

• How could a VAXcluster system be viewed as a single system rather than as individually addressable 
nodes? 

• How could the terminal load be balanced across nodes in the VAXcluster system? 

• How could the management of the terminal servers be automated? 
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Thus the use of the CTERM protocol for terminal servers in both Pluto and Poseidon was halted. (In fact, 
the Pluto project with an RSX kernel was used successfully as the basis for a number of different servers 
in the Ethernet Communications server, or DECSA, family, including the DECnet Router, DECnet 
Router/X.25 Gateway, and DECnet/SNA Gateway products. The same hardware base, though with a 
completely rewritten software kernel, formed the basis for the final Ethernet Terminal Server.) 

However, the original task still remained; therefore, an alternative solution was proposed, based upon work 
done using a new architecture called local area transport (LAT). The LAT solution involved three essential 
components that were unique to that architecture: 

• A new transport and naming architecture to replace the DNA routing, transport, and session layers 

• A new operating system for the terminal server 

• A new "port" driver for the terminal driver of the VMS operating system. 


The Development of LAT 

In late 1981, the prototype of the original LAT server was developed on a VT103 terminal server, which 
contained a small Q-bus backplane with a PDP-11/23 system and an Ethernet controller. (An Ethernet 
controller made by 3COM Corporation was used since Digital had no Ether-net products available at that 
time.) This early work involved quantifying the maximum character-echo delay that a person could comfort¬ 
ably tolerate. We learned that an experienced touch typist encounters difficulties when the echo time 
exceeds 100 milliseconds. By extrapolating from this fact, we deemed that the network and CPU efficiency 
of the entire LAT subsystem should be dramatically improved. The approach was to "procrastinate" for up 
to 80 Milliseconds after characters were received from the terminals at each server. This delay had the 
very desirable effect of reducing the number of messages processed by the Ethernet, the host systems, and 
the terminal servers. (Eighty milliseconds is implementable as a multiple of either the 60-Hz line-frequency 
clock common in the United States or the 50-Hz line-frequency clock common in Europe and other 
countries.) 

In early 1982, we created a VMS driver (LTDRIVER) using a dedicated Ethernet controller to support the 
LAT server prototype. By April 1982, log-in to a VMS system from a server was achieved; about two weeks 
later, the performance relative to the then current multiplexer, the DZ-11, was measured. The LAT 
connection was easily able to out-perform the DZ-11 (a programmed-interrupt controller) under a wide 
variety of loads. Under many loads, the LAT connection was shown to out-perform the DMF-32 (one of a 
number of DMA controllers). 

In early summer 1982, we converted LTDRIVER to the shared Ethernet port driver. This conversion 
allowed a single Ethernet controller to be used simultaneously for LAT soft-ware, and DECnet and other 
communications software. Unfortunately, this change yielded a significant performance degradation. At 
this time, however, the VMS Development Group was designing a lower-level program interface to the 
Ethernet driver that would allow system-level VMS usage of the Ethernet. Currently, this inter-face is used 
to implement VAXcluster support via the Ethernet. 

By late 1982, we decided to include both LAT and CTERM support in the Pluto terminal server, but only 
LAT support in Poseidon. In addition, the original code from the prototype VT103 terminal server was 
migrated to a UNIBUS PDP-11 system; this code was called LAT-11. 

By early 1983, a significant number of VMS developers were using the prototype LAT-11 servers. This 
software was maintained by the LAT developers. It was important that the software worked reliably since 
the VMS developers were using it in developing the VAXcluster software. 

As noted earlier, the original development team for the CTERM terminal server on Pluto experienced a 
number of problems. Therefore, in early 1984, a new terminal server was implemented on Pluto, based on 
the LAT-11 code and not on the RSX software. This new server, containing software only from LAT, was 
referred to internally as Plato. 
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The prototype LAT-11 code was developed into a product to run on version 3.7 of the VMS system. This 
product became available in July 1984, somewhat before VMS VAXcluster support appeared in VAX/VMS 
version 4.0. one month later, the Ethernet Terminal Server, the product name for the Pluto terminal 
server, became avail-able. The risk of having the VAXcluster offering adversely affected by an unproven 
terminal server was limited by releasing it with the earlier version of the VMS system. Thus we took 
advantage of extensive "free" testing from over 1000 internal users. 

In March 1985, the DECserver 100, the product name for the Poseidon terminal server, was released. The 
DECserver 100 implementation was radically different from the other terminal servers. 

DECserver 100 

Although the Ethernet Terminal Server and LAT-11 products provided the benefits of server-based ter¬ 
minal interconnect, they did not fully implement Digital’s terminal server strategy. For server technology 
to become pervasive, it must compete with other terminal connection methods on the basis of cost alone. 
In cluster and multi-host systems, servers provide necessary and desirable added functions. Therefore, they 
should be compared with other connection methods by assigning some value to the additional features and 
then using cost/performance as the deciding factor. In small single-system environments, the added fea¬ 
tures of server technology are not necessarily perceived as adding value; then cost becomes the sole factor 
for comparison. Digital’s servers are at a disadvantage in this situation because they offer features that 
cost more. Digital must pursue a dual path to develop servers for some applications and to maintain and 
expand backplane terminal interfaces for others. 

The first decision we made was an important one: the product would be a local terminal server and nothing 
more. Telephone data lines usually terminate inside computer rooms. There-fore Pluto, which is suited to 
computer room configurations, already filled the need for a terminal server with modem control capabili¬ 
ties. Poseidon was specifically designed to be distributed along an Ethernet throughout an office environ¬ 
ment, near the attached terminals. Of course, multiple Poseidons could also be used in wiring closets and 
computer rooms. 

We also believed that Pluto already provided a hardware base for other communication server applications; 
therefore, Poseidon need not support applications other than terminal serving. Although often desirable 
from the standpoint of the company’s total product set, generality is also the archenemy of low cost. 
Hardware that serves many functions also has capabilities that are unused in some applications. Those 
unused capabilities represent a cost from which no bene-fit is derived when an isolated application is 
viewed. 

On the other hand, hardware designed for a particular application can optimize cost and performance by 
eliminating any unnecessary capabilities. The Ethernet Terminal Server and DECserver 100 illustrate both 
ends of this spectrum. The hardware base for the former functions in a number of general roles related to 
communications, such as the DECnet Router or DECnet/SNA Gateway products. Consequently, this 
product has a high entry cost, but a low incremental cost as each terminal is added. The DECserver 100, 
being a specialized server, has a low entry cost as well as a low incremental cost. 

A second equally important decision was made early in the project: the product managers de-fined and then 
enforced a very aggressive cost goal in terms of dollars per connection. Although some cost reductions 
seemed quite insignificant and not worth the effort, in the end the old adage of "watch the pennies and the 
dollars will watch themselves" proved to be true. The insistence on meeting the cost goal also prevented us 
from adding "bells and whistles" with their associated costs and complexity, to the requirements list as the 
project progressed. 

Work started on the hardware design with a clear cost goal, but with no preconceived requirements for the 
implementation. It seemed fairly obvious that an eight-line server could be built on a single printed circuit 
board. Since there is a substantial expense simply in connecting multiple boards, we decided very early that 
directly incorporating any pieces of existing products was too expensive. The server would be a single 
board designed from scratch, although we were free to borrow design ideas from other products. We also 
decided to use only high-volume, and therefore inexpensive, components where possible - a decision driven 
partially by the desire to shorten the design time. 
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One of the most important issues was making sure there was enough processing power. Since Poseidon 
would not be programmed by customers, the extensive PDP-11 and VAX instruction sets were not really 
needed. We decided finally to use the Motorola 68000 chip, which was the lowest cost, most readily 
available micro-processor with sufficient power. 

As the design progressed, we considered every possible cost reduction option. For example, the dynamic 
EAMs are refreshed by software since sufficient processing time exists to do that; the cost of refresh 
hardware could thus be eliminated. Chips were selected to perform multiple functions whenever possible. 
For example, the terminal interface (UART) chips have integral timers used to control the software 
refresh, the timer interrupt, and the watch dog timer. Essentially, the interrupt logic uses very little 
external logic to turn around the interrupt priority level to generate the vector address. 

Thus the design resulted in an extremely low-cost, fixed-function terminal server, the DECserver 100, 
which has proven to be, by far, the most popular member of Digital’s terminal server family. 

THE LAT ARCHITECTURE 
The LAT Protocol 

One initial goal of the LAT architecture was to connect terminals to host system using the Ethernet as a 
data link. Even today, LAT is still used primarily for connecting terminals to hosts. However, its applica¬ 
tion has spread to connecting other asynchronous devices, such as printers or links to hosts other than 
those directly connected to an Ethernet. 

The goals of the LAT protocol are as follows: 

• To permit dumb terminals to be connected to multiple hosts 

• To be a transparent character transport mechanism (implying that character echo must be performed 
by the host and not by a server) 

• To support a high-bandwidth LAN technology (specifically the Ethernet) 

• To use a fixed maximum bandwidth that is much less than the total LAN bandwidth, which should be 
used in a fair and predictable manner 

• To be an efficient data link protocol, relative to the higher-layer DECnet protocols, such as CTERM 
operating in a LAN environment 

• To provide for low CPU loads and memory use on the host system at the expense of higher CPU and 
memory utilization on the terminal servers 

• To allow for simple terminal server implementations, which means low-cost and high-performance 
hardware implementations 

• To permit automatic configuration so that, for example, servers can determine, without manual 
intervention, the names and addresses of hosts on the Ethernet. 

The LAT protocol makes certain simplifying assumptions: 

• Communication is local to a single logical Ethernet (possibly connected by repeaters and bridges); 
thus no routing capability is required 

• Communication is inherently asymmetric, which simplifies connection management and permits 
straightforward host implementation 

• The bandwidth of the Ethernet (10 megabits per second) is much greater than the band-width needed 
for a given terminal (e.g. 9600 bits per second), so that a timer-based protocol is appropriate. 

The normal model of dumb terminal usage is one of low-speed data entry, say a few characters per second, 
and higher-speed display in bursts of several hundred characters at a time, taking several seconds to 
display. In addition, a user is usually sitting at his terminal while a program operates at the host. LAT 
takes advantage of this asymmetrical relationship. Also, the terminal connection normally takes place at 
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the explicit request of the user rather than of the host system. LAT also takes advantage of this asym¬ 
metric aspect. 

The server does not communicate characters to a host system as they are entered by the user; rather, it 
collects characters and periodically transmits them to the host. The time interval of this period, the 
"circuit timer", is quite short -typically 80 milliseconds. With many users connected, a host is interrupted 
much less often by gathering together all the characters typed by those users and sending them as a single 
message. 

The LAT protocol is divided into two distinct layers, the virtual circuit layer and the slot layer. 

VIRTUAL CIRCUIT LAYER 

The virtual circuit layer establishes and maintains an error-free communications path (a virtual circuit) 
between two nodes, typically a terminal server and a host. The connection is initiated by one end of the 
communications path and operates under the control of the initiator. However, the circuit can be termi¬ 
nated by either end. Typically, the virtual circuit connection is initiated when the first terminal user 
requests a connection to a host system to which no virtual circuit yet exists. The initiator of the virtual 
circuit is referred to as the "master node", the other end as the "slave node." Thus the terminal server is 
normally the master, and the host the slave. 

The establishment of a virtual circuit connection requires a single message exchange. Information such .as 
protocol versions, message sizes, and node names are included in these messages. 

Once established, the data exchange occurs as follows: 

• Every 80 milliseconds, the master sends to the slave a message containing any data that must be 
sent. 

• On receiving this message, the slave processes any data in that message and sends back a reply 
containing any data waiting to be sent in that direction. 

• On receiving this reply, the master processes any data that was in the message. 

• Eighty milliseconds after one message was sent, the next message is sent from the master. 

The message round-trip time is typically less than 10 milliseconds. This operation is timer driven on the 
master, the terminal server, and event driven (by message receipt) on the slave, the host. 

The virtual circuit layer provides reliable communication between a pair of nodes. It also provides a 
datapath that is bidirectional, sequential, timely, and error-free. All users desiring to communicate over 
that path are multiplexed over the same virtual circuit, consequently lowering the CPU cost per user on 
the host. This multiplexing function is the responsibility of the slot layer. 

THE SLOT LAYER 

The slot layer establishes user sessions, transfers data bidirectionally, and multiplexes and demultiplexes 
sessions over virtual circuits. In this context a session can be envisioned as a connection from one user’s 
terminal to one host system. 

A terminal user first identifies the computer system with which he desires to communicate. A virtual 
circuit is then established - if one does not already exist - from the terminal server to the host system. A 
session is then established on top of the virtual circuit. The service access point at the host would normally 
be represented as a virtual terminal port into the host operating system. Thus the user would perceive the 
virtual terminal as being directly connected to the host system. For example, on the VMS system, the 
LOGINOUT function can be run to log in and continue with the normal interactive use of the system. 

At the slot layer, data is passed to the virtual circuit layer as "slots", which are addressed units of data. A 
number of different types of slots have been defined. Each session has a unique slot number on the virtual 
circuit to aid in the multiplexing and demultiplexing of sessions over virtual circuits. Slots are only sent 
over virtual circuit run messages. Because slots all share the underlying virtual circuit, no explicit error 
detection and correction need be performed by the slot layer. 
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The establishment of a session is accomplished using one of the assigned slot types called a start slot. 
First, the master sends a start slot requesting a connection to the slave. If the slave is able to accept the 
connection, it replies with a start slot; if not, due perhaps to lack of resources, the slave may reject the 
connection with a reject slot containing an appropriate reason code. 

Owing to the mismatch of speed between terminal and host, some flow-control mechanism is needed to 
prevent one end from overloading the other. (This mechanism is independent of the flow control required 
between the terminal server and the terminal itself. That control is normally handled by using the ANSI 
flow-control characters XON and XOFF.) 

The LAT protocol defines a credit-based flow-control scheme at the slot layer. In this control scheme, the 
receiver must give permission to a transmitter to send each data unit, containing one or a collection of 
bytes. Data may be exchanged in units of up to 255 bytes in a slot type called a data-A slot. The sending 
of a data-A slot (if it contains any data at all) uses up a single "credit". If one end of a session desires to 
send some data, that end must have a credit outstanding. 

The initial credit allocation is passed in a start slot. There are three additional slot types defined for the 
slot layer. The first, the data-B slot, communicates the following information: 

• The physical port characteristics, such as baud rate, character size, and parity 

• The session characteristics, such as whether the ANSI flow-control characters (XOFF/XON) should 
be treated as data or flow-control messages 

• The in-band signaling of break conditions or signaling errors (parity or framing errors) 

The data-B slot is subject to the same credit mechanism as the data-A slot and indeed shares the same 
credits. 

The next slot type, the attention slot, is not subject to credits and is used for out-of-band signaling. This 
slot is currently used for an abort-output operation (as in cancel output *0). 

A session may be terminated by either end via the final slot type, the stop-slot. Typically, the stop slot is 
sent by the host system after the user logs out of the system. 

DIRECTORY SERVICE 

One goal of the LAT protocol is to permit the automatic configuration of the LAN. The important 
information that needs to be disseminated through-out the LAN is the name of each service that may be 
used. Rather than requiring that each terminal server possess this information a priori, LAT provides a 
mechanism that permits each server to "learn" about the configuration. 

To accomplish this learning process, and additional message type is used, the "service advertisement". 
This message is multicast from each slave node to all master nodes and gives the names of all services that 
the slave node is currently offering. (A multicast message is a single message addressed to and received by 
multiple nodes.) An advertisement is transmitted periodically, typically every 60 seconds. Thus on start-up, 
a server can "listen" for service advertisements and build a directory of available services. This directory 
can be then presented to the user, on demand, enabling him to choose whichever services he wants from 
those available when a connection to a host system is desired. 

There is no restriction that any node may offer just one single service. LAT allows a given node to offer 
multiple services. One common use for multiple service names is in a VAXcluster environment. When a 
user requests a connection to the service name representing the cluster, the terminal server can select one 
of the available nodes. In this case all nodes offering the same service will be presumed to be offering 
identical capabilities to the user. 

To assist the terminal server in choosing a node, the service nodes provide a "rating" associated with each 
service offered. The rating is a numeric value that represents some measure of the resources avail-able to 
apply to that service. For example, the current VMS LTDRIVER implementation takes into account the 
most recent CPU idle time, the CPU type, the amount of memory, and the number of remaining inter- 
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active job slots. VMS LTDRIVER also allows the system manager to specify a rating. The terminal server 
can then choose, at any instant, the node that offers a requested service with the highest rating and use 
that node as the one to which to form the connection. This choice ensures that the load can be shared 
among the nodes in a VAXcluster system. 

By carefully managing the service advertisements, the server makes the service directories reflect the 
current service list and their associated ratings, If a server fails to hear from a service provided for some 
period, the server can assume that the service provided has failed, or crashed. The server can then remove 
the service from its directory of available services. 

The LAT "load-balancing" and "fail-over" features are most often associated with VAXcluster systems. 
However, although they enhance Digital's VAXcluster offering, these LAT features are independent of it, 

"Equivalent services" may also be offered by multiple nodes using the directory service. Consider services 
that are network based, such as Videotex and dial-out modems. With an Ethernet LAN, many independent 
nodes might offer such services; typically, however, users can access the service only through nodes on 
which they have accounts. If a user’s system is down, he is denied access to the service, even though the 
service remains available on other nodes. For example, consider a Videotex-based service, such as 
LIVE_WIRE (an in-house electronic bulletin board), that can be offered by many independent LAT host 
systems. If a LAT user connects to LIVE^WIRE, the terminal server software will detect that the service 
is offered from multiple sources. The software will then make a connection to the source believed to be 
currently offering the best level of service. If that service should fail (i.e. stops sending Ethernet LAT 
messages), the terminal server software will automatically reconnect the user to an alternate provided of 
the same service if one exists; this action is known as fail-over. 

Future versions of Digital’s LAT products may make more extensive use of the LAT service capability. 
That would make it possible to install applications that are accessible to the extended LAN but not to the 
wide area network. A form of nondiscretionary access control is implicit in this design. 

PRODUCT IMPLICATIONS OF THE LAT ARCHITECTURE 

Although not originally conceived as a distributed terminal switch, an Ethernet can be used effectively in 
that role if combined with the terminal server products. This fact remains true even when the Ethernet and 
host system are running other protocols simultaneously, such as DECnet and VAXcluster systems based 
on Ethernet. Our experience has shown that a single dedicated Ethernet segment, without bridges, can 
easily support several thousand concurrent users. 

Functioning as a distributed terminal switch in the Digital computing environment, LAT offers significant 
advantages over dataswitches and backplane multiplexers. The most prominent of these advantages is that 
any terminal server user can connect to any host system. "Blocking" connections to host systems (more 
accurately called "port contention") is not an issue because host-system ports are logical, not physical. A 
VAX/VMS system is limited by the LAT architecture to about 6 million simultaneous connections, or 
32,000 terminal servers, each with up to 255 sessions. This large number rep-resents a significant cost 
advantage, especially considering that Ethernet controllers are standard options on many of Digital’s 
processors. In this case the host-processor terminal connection cost then becomes negligible, making 
backplane-oriented terminal switches much less attractive. This cost advantage improves as the size of the 
system increases. 

Some additional advantages afforded by using LAT are as follows: 

• Multi-session capability, not offered by data-switches 

• Simplified installation and management (especially where users and computer systems are often 
added or moved around) 

• Higher availability due to the lack of any single point of system failure 

• Simplified, incremental expansion and migration capabilities inherent in Digital’s extended LAN 
architecture, utilizing bridges. 
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THE ORIGINAL IMPLEMENTATION 

Digital’s original terminal server family had three members: LAT-11, the Ethernet Terminal Server, and 
the DECserver 100. These LAT products support interactive terminal users. These products use the unique 
naming capabilities of LAT (service names, load-balancing, fail-over, and auto-configuration) and feature 
multi-session support and complete application transparency, The servers implement an easy-to-learn user 
interface that allows users to change parameters, view available services, and connect and disconnect from 
these services. In addition, the same user interface allows a local manager to control the operation of the 
server and ports. The DECserver 100 and the Ethernet Terminal Server also implement a remote console 
feature that allows remote management from the server by using a convenient, centrally located host 
system. 

The LAT-11 product, unlike the other two terminal servers, is a software product. It was originally sold to 
enable users with PDP-11 systems that were no longer being used for general computing facilities to take 
advantage of the server technology, but without incurring any initial hardware investment. The software 
ran on some of the older UNIBUS PDP-11 systems, using 124KB of memory, up to eight DZ-11 multi¬ 
plexers, and a DEUNA Ethernet controller. The software was loaded either via the Ethernet or from a 
local disk. LAT-11 offered a user interface and capabilities similar to those on the original version of the 
Ethernet Terminal Server and could connect up to 64 users to the Ethernet. Being based on PDP-11 
technology, servers using LAT-11 would normally be located in computer room environments. 

The Ethernet Terminal Server uses the Ether-net Communications Server (DECSA) hardware. This is a 
special-purpose PDP-11/24 system with 512KB of memory, a DEUNA UNIBUS-to-Ethernet controller, 
and two protocol assist modules (PAM). PAM’s are intelligent microprocessor-controlled interfaces based 
on the AMD 2901 from Advanced Micro Devices Inc. Each PAM interface connects up to eight line cards, 
each of which is a dual RS232C interface with full modem-control capability. The server also has a console 
boot terminator (CBT) module for self-test code, bootstrap code, and remote console support. The Ethernet 
Terminal Server offers a user interface similar to that on the DECserver 100. Using the LAT protocol, the 
server can connect up to 32 terminals (either locally or remotely via modems) to the Ethernet. The 
Ether-net Terminal Server can be located in a computer room environment or a communications closet. 
The software is always down-line loaded into the unit from a DECnet load host across the Ethernet. 

Internally, the DECserver 100 is radically different from the other two members of the terminal server 
family, yet still retains the same external characteristics. The DECserver 100 is a low-cost terminal server 
capable of connecting eight asynchronous ASCII terminal to an Ethernet using LAT protocol. This server 
is a very compact unit and can be located in a computer room, a communications closet, or in an office 
environment. The server has no modem control. Modem control is implemented using an 8-MHz Motorola 
68000 chip, with 128KB of RAM, and 512 bytes of nonvolatile RAM (NVRAM). Like the Ethernet 
Terminal Server software, the DECserver 100 software is down-line loaded from a DECnet host. 

EXTENSIONS TO THE ORIGINAL IMPLEMENTATIONS 

The initial implementations of the LAT protocol were on the terminal servers described above and on 
VAX/VMS systems. The servers implemented only the master end of the LAT protocol, whereas the hosts 
implemented the slave end. Follow-on implementations have added similar support for additional host 
systems: MicroVMS, RSX-11M-PLUS, MicroRSX, ULTRIX-32, ULTRIX-32m, TOPS-10, and TOPS-20 
systems. Each system implementation offers access to the command interpreter as the service access 
point. 

Version 2.0 of the Ethernet Terminal Server added the reverse-LAT implementation, permitting a server 
to offer additional services to which terminal users can connect. This implementation permits sessions to 
be created within the box as well as across the network, thus forming a switch style of operation in a single 
server. The types of services that may be offered by the terminal server can be grouped into the following 
three categories. 

The first category is connections to non-LAT hosts. In this mode, the server acts as the Ether-net 
connection for systems (typically not made by Digital) that cannot themselves offer LAT services on the 
Ethernet. Asynchronous ASCII ports on these systems are connected to a terminal server. Terminal users 
on the same or different terminal servers can connect to the service offered. They can then communicate 
with the non-LAT host as though it were connected to the Ethernet. 
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The second category is service for dial-out modems. Terminal users can connect to a port in a pool of 
dial-out modems. The users can then use the appropriate ASCII protocol to create a dialed connection and 
then access the remote system via its own dial-in port. 

The third category is service for personal computers (PC), They can be connected to terminal servers and 
run in either of the terminal emulation modes. Each PC thus acts as though it were a dumb terminal. A PC 
can also run in file transfer mode when connected to another PC via the same, or another, terminal server. 

Subsequent versions of the Ethernet Terminal Server, DECserver 100, and the VMS LTDRIVER soft-ware 
all permit asynchronous printers to connect to terminal servers. These versions also allow print queues to 
be directed to the printers from hosts. The LAT protocol has been enhanced so that the connection 
mechanism remains under the control of the terminal server (for efficiency reasons mentioned previously). 
That enhancement allows a host to "solicit" a connection from a port on a terminal server. Once the 
connection has been made, data transfer can occur as in the normal interactive terminal case, except that 
the printer output is under the direction of a VMS print symbiont. It is possible, with these implementa¬ 
tions, to direct the queues from multiple systems to a single printer or bank of printers being offered as a 
common service. When a connection request is made while the printer is being used by another system, the 
connection request can be queued. This queuing provides a basic mechanism for sharing printers among 
multiple systems. Within the LAT environment, the service name offered by a host system does not always 
have to represent the command interpreter on a given system, though this is by far the most common use 
today. Instead, a service name could represent an application program, which might be run automatically 
when a connection request is made. Alternatively, using the solicited-connection mechanism currently 
employed for printers, application programs could initiate connections to terminals (or other asynchronous 
devices) located within the LAN. 

DECSERVER 200 

The DECserver 100 interconnects terminals in an office environment at a very low price. Soon after it was 
announced, it became clear that modem-controlled lines and connections to non-LAT host systems should 
also be priced just as low. 

Thus the DECserver 200 project was initiated to produce a new server based on the DEC-server 100 
design, but with modem control capabilities. Moreover, this product had to meet the original cost goals of 
the DECserver 100. This project involved a redesign of the printed circuit board, yet retained the same 
system architecture. A faster version (10 MHz) of the same MC68000 microprocessor was used, and 
memory was increased from 128KB to 384KB of RAM and from 512 bytes to 2KB of NVRAM. This 
increase allowed room for the implementation of modem control software and support for non-LAT hosts 
(i.e. reverse-LAT capabilities). The increase also allowed a larger service directory database to be stored and 
an enhanced on-line help capability to be added. 

Another feature of the DECserver 200 takes advantage of the DECconnect cabling scheme, allowing 
connections to be made using DEC423 wiring. This feature allows communications at up to 1J.2 Kbaud 
over cable that is neither twisted pair nor shielded, for relatively long distances of up to 1000 feet. 

SUMMARY 

Unlike other existing packet-oriented transport layer architectures, the LAT transport layer implements 
asymmetric connection management, asymmetric data flows, and timer-based message exchanges. 

The most unusual innovation of the LAT architecture is the use of multicasting as a presentation level 
naming service. On Ethernet, packets are normally addressed to the adapter of a specific system. However, 
the Ethernet specification de-scribes a form of logical addressing called multicast addressing. In this 
scheme a packet addressed to a multicast address is received nearly simultaneously by many independent 
systems. LAT uses these messages to completely configure the topology automatically. This action means 
that installing a terminal server is as simple as plugging it into the Ethernet and waiting for services to be 
advertised. 
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Asymmetric connection management considerably simplifies the complexity of the protocol in which ter¬ 
minal servers initiate connections to host systems. If a host system wants to connect to a terminal server, 
that connection must be solicited from the terminal server. This protocol solves the problem of having 
many host systems competing independently for the same resource. The first "solicitation" is serviced by 
a connection, and subsequent requests are queued on a first-in, first-out basis. 

On a particular terminal server, all devices that are logically connected to the same host system share 
messages both to and from that host. Within each message, each users’ data is contained within slots. This 
multiplexing, in conjunction with the delay timer, reduces further the number of messages exchanged. For 
example, as more users log in to a host system, the number of messages exchanged remains constant at 
approximately 12 per second in each direction, even as the lengths of the messages increase. 

The DECserver 100 and DECserver 200 are low-cost implementations of the LAT architecture, allowing 
terminals and other asynchronous devices to be configured in a flexible and cost-effective manner in a 
LAN. 
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FROM THE EDITOR... 


We have a short issue this month featuring the return of our Notes column! 

Many thanks to those of you who took part in the reader survey last fall. The comments and information 
you provided about the OA section were very helpful to us in structuring the content of future issues. 

Keep an eye on August and September issues for post-Symposia articles, informationa and the new SIR 
listing. 

Regards, 

Therese LeBlanc 
OA Newsletter Editor 
275 London Place 
Wheeling, IL 60090 
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NOTES ON NOTES 


Discussions on VAX Notes 
Volume 2, Number 1 

Mark Hyde and C.J. Trayser, Digital Equipment Corporation 


Well, its been a while since we wrote the last article. We have both been quite busy with new jobs (Buck is 
now an Educational Services Instructor and Mark is busy supporting VMS and DECnet). There are still 
many things to write about so we will be sending in articles every now and then, but not quite so regular 
as last year. Volume 2 will consist of more occasional articles written by one or both of us as we encounter 
interesting topics. 

In the past we discussed a lot of user features, but left the system management issues lightly covered. So 
we will try to cover some of those in this article. 

In the pre-sales cycle we are often asked "How much disk space does VAX Notes use?" Well, as you can 
probably guess, the answer is "It depends." There are three distinct "consumers" in disk space: 1) the 
installation, 2) the conference creation/growth and 3) users notebooks and storage. 

The installation is usually the smallest user of disk space over the long run. The space used depends 
slightly on the version, but all use less than 3000 blocks. Most of this space is for shareable images and 
TPU code for the user interface. There are several small files, such as some command files, and a few 
executables in SYS$SYSTEM and the NOTES$LIBRARY directories. The other file of significant size is 
the sample conference which is placed in the NOTES$LIBRARY directory. 

A major user of disk space (and the hardest to manage) is the individual user. The space is used in three 
ways: 1) extracting notes to text files, 2) creation of personal conferences and 3) growth of 
NOTES$NOTEBOOK.NOTE. Although extracting notes and creating conferences are obvious uses of disk 
space, the (unknown) growth of a notebook can be quite amazing. Because of the way VAX Notes keeps 
track of which entries are seen and unseen in the notebook, (a topic for another article) it can grow to 
enormous proportions unless it is managed. Since the notebook file is formatted and organized the same as 
a conference file, the same routines for compression can be used quite effectively on both conferences and 
notebooks. Here is an example command procedure that can be used to compress these files. 


$! NOTEFILE_CONVERT.COM 

$! 

$! To use this procedure supply the name of the file to compress such 
as... 

$! 

$! @N0TEFILE_C0NVERT.COM SYS$L0GIN:N0TES$N0TEB00K.NOTE 

$! 

$ fdl = f$parse(f$environment("default")+".fdl",pl) 

$ analyze /rms /fdl 'pi /output='fdl 

$ edit /fdl /analysis='fdl /nointeractive 'fdl /output='fdl 
$ convert /fdl='fdl 'pi 'pi /statistics 

The most obvious consumers of disk space are the conference files. 
Physically these are indexed-sequential files which are subject to most of 
the standard "symptoms" of indexed files. Among these problems are growth 
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and fragmentation - both of which can be managed but not necessarily 
controlled. 

These files are the actual repositories of the data (notes, replies, etc.) 
of a conference. As such, they grow in direct proportion to the amount of 
data that is placed in the conference. Other than the compression routines, 
which will only help minimally, deleting information from the conference is 
the only way to shrink, a conference. The problem with this is that a 
subjective decision must be made as to what information should be deleted. 

We say "subjective" because the use of each conference may differ, therefore 
deleting notes due to a specific measurement, such as age, may not be 
reasonable. 

As the conference continues to grow its size can become cumbersome. We have 
seen some conferences with over 10,000 entries consuming thousands of disk 
blocks. Among other things this makes incremental backups take longer 
because with any change or addition to the file it is marked as modified and 
a backup routine looking for modified files will encounter a potentially 
huge conference. To accommodate this we suggest "retiring" conferences 
periodically. One way to do this would be similar to our hypothetical 
conference on Trucks; 


1. A note should be posted (possibly a reply to topic 1.0) that all new 
discussions should be started in the next version of the TRUCKS 
conference called TRUCKS_V2. The note should be modified to allow 
the participants to press the SELECT key to add the conference to 
their notebook: 

Notes> SET N0TE/C0NFERENCE=MYN0DE;:TRUCKS_V2 

2. Modify the Conference Notice about a week or more ahead of time 
that the conference will be retired and that they should read 
note number 1.x for more information. 

Notes> SET C0NF/N0TICE="Conference being retired. See note 1.4" 

3. At the prescribed time the moderator sets the old conference to 
disable writing (and replying), 

Notes> SET C0NF/N0WRITE 

modifies the NOTICE and posts a follow-up note indicating the 
conference is closed. This is best done when the moderator knows 
there is no one accessing the file to avoid any confusion. 

4. Generate a full directory listing of the old (retired) conference 

Notes> DIRECTORY *.* /0UTPUT=TMP.LIS 

and post this as a note in the new conference - preferably as 
one of the first topics or even as a reply to 1.0. 

5. The retired conference file should have the file protection set 
to (S:RE,0:RE,G:RE,W:RE). This will allow anyone to access the 
file to read it, but prevent them from writing to it. This is 
sometimes necessary as any MODERATOR can get past the /N0WRITE 
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setting, but unless they have exceptional VMS privileges, this 
prevents accidental writings by the moderators. 


After a period of time it may be reasonable for the file to be archived to 
tape so the moderator can delete the file, saving disk space. This is a 
judgment call as it depends greatly on the contents of the file. 

In addition to disk space, VAX Notes can be a consumer of network resources. 
Assuming you have VAX Notes running on several nodes in your network and you 
access conferences on other nodes, this can be a point of concern. If you 
have the most popular conference in the company on your node, you may find 
that there are large numbers of network links to the Notes server on your 
system using up resources that you would rather be using somewhere else. If 
you have a lot of other network activity, you may even bump into the maximum 
links limit specified in your DECnet parameters. 

The VAX Notes server is multi-threaded, which means that many links at once 
can be serviced by a single server process. By default the maximum number of 
links handled by a single server is 16. When the maximum number of links on 
a server has been reached, Notes will obligingly fire up another server to 
handle another 16 links. By default there is no maximum number of servers 
that will be started. 

Unless you are used to using NCP to view the total number of links into your 
system, you may not perceive either of these things happening. Of course, 

VAX Notes offers a way to control both the number of links per server and 
the number of servers as well as monitoring them. To see how many VAX Notes 
server processes are on your system issue a SHOW SYSTEM/NETWORK command at 
DCL and looking for the processes that look similar to the following: 

VAX/VMS V4.7 on node BATON 6-APR-1988 20:16:02.55 Uptime 12 01:31:37 
Pid Process Name State Pri I/O CPU Page fits Ph.Mem 

20200725 EVL HIB 6 1109 0 00:00:22.84 47621 51 N 

202003B8 N0TES$000E_1* HIB 4 148 0 00:00:03.78 653 45 N 

In this case, the VAX Notes server process is the one with the process name 
of "N0TES$000E_1*". The interesting items are actually part of the process 
name. The asterisk ("*") indicated that this is the "declared" server, or 
the one that will accept the next incoming VAX Notes link. The number in 
front of the asterisk, in this case the "1", indicated how many links this 
process is currently serving. 

You can modify the default number of servers as well as the default number of 
links per server via logicals. As a rule the defaults will be fine except in 
the busiest of VAX Notes environments. However, if you feel they need 

adjusting, you can adjust the following logicals to either increase or 

decrease the defaults. 

$ DEFINE /SYSTEM /EXEC NOTES$SERVER_MAX_SERVERS 4 !per system 

$ DEFINE /SYSTEM /EXEC N0TES$SERVER_MAX_LINKS 16 !per server 

Happy Noting :-) 
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PROTO SYSTEMS Memory Upgrade - A Review 

By Gary Rice , PC SIG Newsletter Editor 

For the last several weeks, I have been using a 1 megabyte PRO 350. Now, for those of you who have a 
Macintosh or a VAXstation, this may not seem like a "big deal". But for me as a PRO user, it was quite a novel 
experience. For the first time, I could actually install my Ethernet card. Now what does a memory upgrade 
have to do with an Ethernet card? Well, the PROTO SYSTEMS memory upgrade consists of either 1 or 2 small 
cards (your choice) that attach to the system board directly. When I installed the first card, I was able to 
remove the memory board that occupied one of the option slots on the CTI Bus. This freed up a slot (that I used 
for the Ethernet card) and still gave me the same amount of memory that I had before (512K) which is the 
minimum required for P/OS version 2 or above. 

The PROTO SYSTEMS card is an "exact replacement" for the small (3" x 5") daughter memory cards attached 
to the system board on the PRO 350. However, there is an important difference. The original memory card from 
DEC has a capacity of 128K bytes while the PROTO SYSTEMS board has a 512K bytes capacity. This is done 
through PROTO SYSTEMS use of newer technology chips. The PROTO SYSTEMS board also uses fewer 
components than the DEC board. More on that later. 

The shipment from PROTO SYSTEMS arrived containing 2 memory boards and installation/troubleshooting 
instructions. It was well packed with ’bubble-pack" and anti-static wrappers for the 2 boards. 

Installation of the boards was simple. The instructions provided by PROTO SYSTEMS were clear and easy to 
follow. However, I found 2 things that were 1) annoying; and 2) confusing. The annoying part was the step in the 
instructions that stated that I needed to detach all of the peripheral connections from the back of the system. 
You know, the printer, MODEM, TMS, etc. Well, the only one that I ACTUALLY needed to remove was the 
power cord. The confusing part was the area of the instructions describing the removal of the old memory 
boards. The instructions were somewhat unclear about this. 

However, I succeeded in installing BOTH boards without any real trouble and both came "on-line" without 
error straight from the box. 

To verify that I actually had a 1 megabyte system, I issued a "$ SHOW MEMORY" command from the Toolkit. 
Here is a pictorial of the resulting display on the next page. 
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The "512K" on the first line did INDEED indicate that I actually had 1 megabyte, since the text reports the 
number of 2 byte WORDS available to the system. 

Next, I decided to make some comaprisons between the PROTO SYSTEMS board and the DEC equivalent the 
MSC11-B memory board. The DEC board is specifically sold as a PRO 380 option, but it will work in the 350 as 
well. It is a 512K daughter board similar to the PROTO SYSTEMS board. I happened to have one of the DEC 
boards so I could make some legitimate comparisons. 

Physically, the two boards are the same size. The number of components on each board is different. The DEC 
board has 61 while the PROTO SYSTEMS board has 37. The memory chips on the DEC board were Japanese. 
The PROTO SYSTEMS board used Korean chips. Both boards used a double sized foil design, but the foils on the 
DEC board tended to have narrower control and power foils than the PROTO SYSTEMS board. 

To see if there were any differences in performance between the two boards, I set up the following test. First, I 
wrote a simple memory access program. The listing appears at the end of this article. Then, I ran the program 
10 times with the DEC board installed in the PRO 350. Next, I removed the DEC board and substituted the 
PROTO SYSTEMS board. I ran the program again 10 times. The differences that I found are detailed in the 
table that follows. The numbers listed in the table are the averaged results for both reading from and writing to 
a program memory location 1,000,000 times. 

To summarize the information that I have previously presented, on the next page is the comparison in table 
form. 
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DEC 

3"x5" 

61 

Japanese 

572 

15.870313 sec 
14.092188 sec 


Card Size 
Components 
Chip maker 
Cost 

Timing results 
averaged read 
averaged write 

I will leave it up to you to decide if these numbers are significant. 


PROTO SYSTEMS 
3"x5" 

37 

Korean 

250 

15.892188 sec 
14.078125 sec 


Just for fun, I ran the same test program on a PRO 380 (using a DEC board) and came up with the following 
timings: 

read 7.406250 sec 

write 7.015625 sec 


PROTO SYSTEMS is located at 1238 Josephine Street, Berkley, CA, 94703. Contact Everett Harvey (phone 
(415)420-9579) for more information. 


Timing program 


BYTE JUNK(10000) 

C 

REALM SECNDS, A, B, C 
C 

A = SECNDS (0.0) 

DO 400, K = 1,1000 

DO 200,1 = 1,250 
JUNK© = I 
JUNK(I+7000) = I 
200 CONTINUE 

DO 300,1 = 1,250 

JUNK(I+500) = I 
JUNK(I+7500) = I 
300 CONTINUE 

400 CONTINUE 

B = SECNDS(A) 

A = SECNDS (0.0) 

DO 600, K = 1,1000 

DO 500,1 = 1,500 

J = JUNK© J = JUNK(I+7000) 
500 CONTINUE 

600 CONTINUE 

C = SECNDS(A) 

WRITE (5,10) B 
WRITE (5,10) C 
10 FORMAT (1X,F10.7) 

END 


PROgramming Quickie 

By Gary Rice, PC SIG Newsletter Editor 

This month's "Quickie” consists of a MACRO subroutine (callable from the high level language of your choice) 
that will create a contiguous file of any size AT A SPECIFIC LOCATION on the disk. You can do the same thing 
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with the PRO/Toolkit program RMSDES.TSK, but this routine let me do it from an application that I wrote. 
The routine itself is listed first followed by a FORTRAN fragment showing the calling sequence. 


; CREATE.MAC - This subroutine CREATES a sequential file of a specific size at a specific place on the disk. 

; AUTHOR: Gary Rice 

; CREATED: January 2,1988 

; REVISIONS: None 

/ 

; INPUTS: INI - INTEGERS Number of characters in device-directory-file name 

; IN2 - CHARACTERS The device-directory-file name 

; IN3 - INTEGERS The block on the disk where the file should start 

; IN4 - INTEGERS The size of the file 

; OUTPUTS: OUT5 - INTEGERS RMS Open completion code from STS field 

; OUT6 - INTEGER*2 RMS Open completion code from STV field 

/ 

; NOTES: This routine uses logical unit #1 to create the file. The 

; LUN must NOT be in use when this routine is called. 

/ 

; The file will ALWAYS be contiguous or no file will be created. 

/ 

; If the requested disk location is in use, RMS will attempt 

; to create the file as close to the specified location as it 

; can. 

/ 

. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 


.TITLE CREATE 

.IDENT /VI .0/ 

/ 

; Global definitions 

.GLOBL CREATE 

/ 

; RMS Macros 

; .MCALL POOL$B,POOL$E 

.MCALL FAB$B,FAB$E,XAB$B / XAB$E 

.MCALL $CREATE,$STORE,$CLOSE 

/ 

; Parameter offsets 

IN1=2. 

IN2=4. 

IN3=6. 

IN4=8. 

OUT5=10. 

OUT6=12. 

r 

; Data section 

.PSECT DATA,RW 
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.EVEN 




FABBLK: 

FAB$B 

F$ALQ 

10. 

; File size - ignored here 


F$BPA0 



; No private buffer 


F$DNA0 



; Default file name 


F$DNS0 



; Length of def file name 


F$FAC 

FB$WRT 


; Block WRITEaccess requested 


F$FNA0 



; File name - run time 


F$FNS0 



; File name length - run time 


F$FOP 

FB$DLK!FB$CTG 

; No lock on abnormal close & Contiguous 


F$LCH 

1 


; LUN assigned to the file 


F$MRS 

512. 


; Maximum record size (bytes) 


F$ORG 

FB$SEQ 


; Sequential file 


F$RAT 

FB$BLK 


; Carriage control = ’NONE” 


F$RFM 

FB$FIX 


; Fixed length records 


F$XAB 

ALLBLK 


; Use an ALL block for locatability 

/ 

FAB$E 




/ 

.EVEN 




ALLBLK: 

XAB$B 

XB$ALL 


; Set up ALL block 


X$AID 

0 


; Use area 0 for this block 


X$NXT 

0 


; No more XAB blocks follow 


X$ALN 

XB$LBN 


; Logical block alignment 


X$AOP 

XB$HRD!XB$CTG 

; Hard area location & contiguous 


X$ALQ 

0 


; Allocation size (filled in at run time) 


X$LOC 

0 


; Placement filled in at run time 

/ 

XAB$E 



; That’s it for the XAB 

/ 

.EVEN 




/ 

POOL$B 



; Pool buffers 


P$FAB 

1 


; One for the FAB 


P$BDB 

1 


; and the ’’Buffer Descriptor Block” 


P$BUF 

512. 


; Buffer size 


POOL$E 



; That’s it for RMS Pools space 


.EVEN 


; Double words are needed for the starting block and file length 

START: .WORD 0,0 

SIZE: .WORD 0,0 


; Executable code 

.PSECT CODE,RO 

CREATE: .EVEN 

/ 

; Store file name addr and length in file access block (FAB) 

MOV #FABBLK,R1 ; R1 = addr of the FAB 

MOV @IN1 (R5),R2 ; Get count of file name chars 
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$STORE 

R2,FNS,R1 

; Store count in FAB 

MOV 

IN2(R5),R3 

; Get addr of file name 

$STORE 

R3,FNA,R1 

; Store addr of file name in FAB 

MOV 

@IN3(R5),START 

; Get the starting block number 

MOV 

#ALLBLK,R1 

; R1 = addr of the ALL 

$STORE 

START,LOC,Rl 

; Put the block # in the ALL block 

MOV 

@IN4(R5),SIZE 

; Get the # of blocks to allocate 

$STORE 

SIZE,ALQ,R1 

; Put the # of blocks in the ALL block 

the file. 

MOV 

#FABBLK,R1 

; Get addr of FAB 

$CREATE 

R1 

; CREATE it 

MOV 

0$STS(R1),@0UT5(R5) ; Get STS error ststus 

MOV 

0$STV(R1 ),@OUT6(R5) ; Get STV error value 

$CLOSE 

R1 

;CLOSE the file 

RTS 

.END 

PC 

; & return 


A sample call to the "CREATE" routine looks like this: 

INTEGERS START, SIZE 
INTEGERS ERROR(2) 

C 

START = 200 
SIZE = 100 

CALL CREATE (26/SY:[USERFILES]MYFILE.TMP;l',START,SIZE, 
+ ERROR(l),ERROR(2)) 

END 


This program will create a file starting at disk block 200. It will be 100 contiguous blocks long. 

Send me your own PROgramming Quickie and I will publish it here in this on-going column in these 
Newsletters. (RX50 Please) 


Printing Macintosh Output on Your DEC Postscript Printer 

By Mark Sebern, Sebern Engineering Inc., P. O. Box 268, Cedarburg, Wl 53012 
414/375-2200 

Introduction 

As even DEC and Apple have belatedly figured out, many DEC users also have a Macintosh. Some such users 
even have DEC Postscript printers, and would like to use them to print Macintosh output intended for a 
LaserWriter. If you have a big system with a lot of Mac's, one way is to use commercial products which 
implement Appletalk on a VAX. For a small user with a single Mac, though, this is not very cost effective. It 
may be old news, but I did stumble across a cheaper way to get Macintosh laser output on a DEC printer. 

The Environment 

I am running a Macintosh SE with 20 Mb hard disk, a VAXstation II/GPX, and an LN03R Scriptprinter. The 
Mac is hooked to the VAXstation via a DHQ11 (TXcn:) port, with Red Ryder on the Mac. The only printer on 
the Mac itself is an Imagewriter II. 
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Making a Postscript File 

The first step is to get the Mac to produce a Postscript file instead of looking for a LaserWriter on Appletalk. To 
do this, install the LaserWriter driver and use the Chooser to select the LaserWriter. It will want to turn on 
Appletalk, which is ok, but turn off your Imagewriter first unless you want to see a lot of garbage. The Chooser 
won't be able to find any LaserWriters, but once you have selected the LaserWriter and enabled Appletalk, just 
click on the close box to leave the Chooser. 

Next, go into your favorite application. I have tested this technique with Microsoft Word, Superpaint, and 
HyperCard. Select the print function as usual, but when it comes time to OK the actual printing, quickly press 
and hold the OPTION and F keys immediately after saying OK. If you are successful, you will get a message 
that says "creating Postscript file" instead of "looking for LaserWriter". If you're too slow, just wait for it to 
give up, and then tiy again. With HyperCard, it's a little trickier, since the normal print setup box does not 
appear, but it still works if you press OPTTON-F at the right time. 

Now, exit the application and look around for a file with the name "Postscriptn", where "n" is a digit. 
Normally this file will be in your "root" folder, but it may take a little looking. If you open this file with your 
favorite word processor, you will see the desired Postscript instructions. Step one is now complete. 

Getting the Laser Prep File 

Unfortunately, the Postscript file you produced above depends on some Postscript definitions which are stored 
in the "laser prep" file in the system folder. In older systems, you could use a variant of the OPTION-F trick to 
get that file, too, but not any more. 

The solution here is a piece of shareware called "AddLPrep" which is available on the CompuServe MACPRO 
Forum as ADDLPREP.SIT, and requires Stufflt for unpacking after downloading. You can get Stufflt from the 
same forum's data library. Stufflt is also shareware, but carries a fee only if you use it for packing uploads. 
AddLPrep creates a file which contains both your original Postscript file and the laser prep file. In my 
experience, you really only need to do this once, since the prep file can be concatenated onto the beginning of any 
Postscript file later created with OPTION-F. Take a look at it with an editor or word processor and you’ll see 
what I mean. 

Getting the File to the Printer 

The files I wanted to print were fairly short, so I just used Red Ryder in straight "ASCII send" mode to dump 
the files up to the VAXstation. Then I printed the files using a Postscript queue on the LN03R. Other file 
transfer techniques (including a Mac implementation of DECnet) could probably be used. Although I didn’t try 
it, I suspect that you could use a Mac communication program to dump the combined file directly to an LN03R 
connected to the Mac's communication port. 

7While sophisticated techniques may be more flexible, this simple process allows inexpensive Macintosh 
output on a DEC Postscript printer. If you need a modest amount of high quality output and don't want to buy two 
laser printers or an expensive network, it may be just the ticket. 
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Editor’s Corner 


By now everyone should have recovered from the Cincinnati Symposium. I 
was unable to attend, so my recovery was swift. If you were a speaker 
whose notes/slides didn’t make it into the Unisig Session Notes, please send 
them to me and I'll publish them here. If you attended a session that you’d 
like the notes from, and those notes didn’t make it into the Session Notes, 
let me know and I’ll try to get a hold of the speaker and publish the notes. 

Turning to this month’s newsletter - First, we have Using ucbmail from 
Steve Gilgut. Steve has included some very handy reference sheets for 
ucbmail. Great for those of us who learned a couple of functions when we 
first learned how to use mail, and haven't learned anything new since (at 
least, in the mail area). Next, our esteemed Unisig Chairperson has 
contributed Unix as a Window to the World, about Usenet and the new 
UUNET. And last, The Way It Is, pulled from Usenet and submitted by 
Steve Gilgut. I suppose we could categorize this last article as the Joke of 
the Month, though it’s probably only funny to a certain segment of the 
computer-literate population. For those who don’t see the humor. I’d be 
happy to print opposing viewpoints. I am a firm believer in freedom of 
expression for anyone who sends me something to publish. 

As always, your comments, suggestions, articles are encouraged and 
welcomed. Please send hardcopy to : 

Sharon Gates-Fishman 
NDC Systems 

730 E. Cypress Ave. 

Monrovia CA 91016 


or e-mail to: 


amdahl! ci t-vax! ndc! sgf 
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Using ucbmail 


First, to elliminate confusion, when I speak of UNIX, I refer to 4.2 
Berkeley, or Ultrix. I don't do System V (yet...). Unix, generally comes 
with two flavors of mail, /bin/mail, and /usr/ucb/Mail. The first is the 
original mail utility, that (I believe) came from AT&T. To supplement this, 
Berkeley put out Mail, sometimes called ucbmail. Ultrix V2.0 also provides 
both. 

The ucbmail version supports many features; among them, the ability to 
drop into the editor of your choice, have a local configuration file, which is 
named .mailrc, and a multitude of others. 

Most users have /bin ahead of lusr/ucb in their PATH variable. Typing mail, 
gets you /bin/mail. Mail is usually linked to /usr/ucb/mail as well, so a simple 
path change will allow you to use mail instead of /bin/mail. 

If you use csh, another way is to define an alias, as in: 

alias mail Mail 

This gets you Berkeley mail by default. An easy way to tell which version 
you are using is by the prompt you get when you are reading your mail. If it 
is a ?, you are using /bin/mail. The & denotes /usr/ucb/Mail. For your 
enjoyment, I have added as a supplement, my Mail Users Quick Reference 
and Command Summary sheets. 

Take a quick look at these before you read on.... 

Confused? Good. Lesson 2.... 

Mail programs in general, are like most Ice Cream. You can't please all the 
people, all of the time. As a result, there are many public domain mail 
interfaces. To name a few, uumail, MUSH, Elm, and SMAIL. Some of these 
resolve internet addresses, do auto-routing, (such as figuring out the path to, 
say, joe@ucbvax [Hi Joe!]), while others provide curses style user interfaces, 
and even Sun style icons of rural mailboxes. It really ends up being a case of 
whatever turns you on. 

I also should mention that almost every one of these mailers has a command 
set that’s somewhat unique to it. A lot of the commands are the same, but 
there seems to be new and different functionality in each. The power in 
some of these staggers the mind. 

Steve Gilgut 

Steve Gilgut, Compugraphic Corp. Wilmington, Mass. 01887 (617)658-5600 X5277 
UNISIG Suite/Campground Coordinator; DECUS U.S. Chapter 
"Of all the things I’ve lost, I miss my mind the most." 

... !{decvax,ima,ism780c,ulowell,laidbak,denning,wizvax,cgeuro,cg-f}!cg-atla!gilgut 
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Ucbmail Qwick Reference Sheet 


previous 

? nelp 

! shell 


Print 

prints ignored 

Reply 

Reply to originator only 

Type 

like Print 

alias 

print, or change arg 

chdir 

cd 

copy 

save, no delete 

delete 

delete 

dp 

delete, print next 

edit 

text editor 

exit 

exit, no chage 

file 

folder 

folders 

list folders 

fo 

current folder name 

fo# 

previous 

fo file 

switch file 

fo % 

switch to system mbox 

fo & 

switch to $HOME/mbox 

from 

header contents 

headers 

list headers 

help 

? 

hold 

save in system mbox 

ignore 

add to ignore list 

mail 

mail to user 

mbox 

save in $HOME/mbox 

next 

print next 

preserve 

hold 

print 

prints 

quit 

quit, save in $HOME/mbox 

reply 

reply to all 

respond 

same as reply 

save 

append to file 

set 

set option 

shell 

shell 

size 

prints size 

source 

read commands from file 

top 

print top lines 

type 

print 

unalias 

reverse alias 

undelete 

marks as NOT deleted 

unset 

reverse set 

visual 

editor 

write 

save 

xit 

exit 

z 

presents headers + forward 

z- 

move backward 


"!cmd 

shell 

"c 

add to CC 

“d 

read dead.letter 

"e 

editor 

"f 

read in msg 

"h 

edit header 

"m 

same as 'f with > 

'P 

print msg 

'q 

abort 

"r 

read in file 

's 

subject 

"t 

add to list 

"v 

editor 

~w 

write msg out 

Icmd 

pipe for filter 


precede by" 

append 

append to mbox 

ask 

for subject 

askcc 

forCC 

autoprint 

d like dp 

debug 

doesn’t work 

dot 

period is terminator 

hold 

save in system mbox 

ignore 

break & cntl C off 

ignoreeof 

ignore cntl D 

metoo 

sender included 

nosave 

no dead.letter 

quiet 

supress version 

verbose 

doesn’t work 

EDITOR 

your editor 

SHELL 

your shell 

VISUAL 

your editor 

crt 

length before "more” 

escape 

escape character 

folder 

path for folder storage 

record 

path to record outgoing 

toplines 

# of lines with top 
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commands in mail: 


? 

! 

Print 

Reply 

Type 

alias 

alternates 

chdir 

copy 

delete 

d P. 

edit 

exit 

file 

folders 

folder 


from 

headers 

help 

hold 

ignore 

mail username 

mbox 

next 

preserve 

print 

quit 

reply 

respond 

save file 

set 

shell 

size 

source 

top 

type 

unalias 

undelete 

unset 

visual 

write 

xit 

z 


Ucbmail Summary Reference Sheet 

prints previous message 
prints help 

executes shell command 
Like ’p’, but prints ignored lines 
Reply to originator only 
like Print 

no arg prints all defined, arg prints arg. args sets or changes arg 

setmail handles this, don't bother with it 

change working directory 

same as save, but no delete 

marks as deleted 

delete, then print next 

invoke text editor on msg 

exit, no chages to anything 

same as folder 

list names of folders in folder dir 
(fo) fo - print current folder 
fo # -previous folder 

fo + filename -switch to filename in folder dir 

fo % -switch to system mbox 

fo & -switch to $HOME/mbox 

prints contents of headers 

prints list of headers 

same as ? 

save messages in /usr/spool/mail/yourlogin 
add list of header fields to ignore list 
mail to a user 

default action (save in $HOME/mbox) 
print next message 
same as hold 
prints message 

quit, saving unresolved in $HOME/mbox 

reply to all people in header 

same as reply 

append to end of file 

set an option 

jump into a shell 

prints size of message 

read mail commands from a file 

print top few lines of message 

same as print 

reverse of alias (undefines) 
marks a message as NOT deleted 
reverse of set command 
invokes display editor 
same as save 
same as exit 

presents msg headers in windofuls. 
move forward: z 
move backward: z- 
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Tilde Escapes 


"! command 

execute shell command 

"c name ... 

add names to CC list 

"d 

read in dead.letter 

"e 

invoke text editor 

'f messages 

read in a message 

"h 

edit the header 

"m messages 

same as "f, but shift right 1 tab 

■p 

print message as is so far 

'q 

abort this message (like 2 breaks) 

“r filename 

read in filename 

~s string 

makes a subject field 

"t name 

add name to recipient list 

"v 

invoke display editor 

"w 

write msg into file 

Icommand 

pipe through command for filtering 

‘"string 

insert string preceded by a " 


Set Options For .mailrc 

append 

append to mbox rather than prepend, is default 

ask 

prompt for a subject 

askcc 

prompt for CC list 

autoprint 

d command behaves like dp 

debug 

doesn't seem to work, should be like verbose 

dot 

a period is the terminator, is default 

hold 

always save messages in /usr/spool/mail (bad idea) 

ignore 

break & cntl C ignored 

ignoreeof 

ignore cntl D 

metoo 

sender included in group alias 

nosave 

don’t make dead.letter files 

quiet 

supress version when mail is invoked 

verbose 

doesn’t work either, see debug 


Set Options With A String Value 

EDITOR 

set to your favorite editor(line or screen) 

SHELL 

set to your favorite shell 

VISUAL 

set to your favorite editor(screen) 

crt 

msg length before "more” is invoked on it 

escape 

the escape character, default is " 

folder 

path/directory for folder storage, like _Mail 

record 

path/file to record all outgoing mail 

toplines 

number of top lines to print with top command 
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Unix as a Window to the World 

In formal Communications Networks 


by 

Kurt L. Reisler 
Hadron, Inc 
9990 Lee Highway 
Fairfax, VA 22030 
USA 

luunet! hadron !klr 


Much has been said of the portability of the Unix operating system, and its 
suitability as a development environment. Articles have appeared in 
numerous publications discussing the distributed file systems techniques 
available to unix systems. However, there is another aspect to unix 
networking that is often overlooked. This is the uucp network or Usenet. It 
is the implementation of the uucp network and its capabilities that make the 
Unix operating system and the unix community unique. Because of its 
capabilities, there are more unix users and developers in communication with 
each other on a world-wide basis than any other operating system 
community. In a sense, the Usenet community is a technical window on the 
world. 

Unix as an operating system is remarkable. It has developed into an 
operating system that is used on a huge variety of hardware suites, of various 
manufacture, of dissimilar hardware configurations, and of a wide range of 
computing power. Variants of the Unix operating system are found on 
systems as small as personal computers, and as large as super computers. Yet 
all of these unix systems have many things in common, including the heart of 
usenet, the uucp programs. 

The uucp programs were originally envisioned as a means of copying files 
between unix systems. Extensions to the original concept have also provided 
the ability to execute commands between unix systems. The logical 
extension of the uucp programs is to use them to move mail messages 
between systems. After all, a mail message is nothing more than a file. The 
final piece that makes unix connectivity on the informal Usenet complete is 
the fact that uucp connections can take place both between directly 
connected systems, and systems that are only connected through the 
telephone system. This allows users on one system to communicate with 
users on another system on a regular basis, regardless of the physical location 
of the systems. All of these parts combine to form a very large, informal 
computer network that is composed of heterogeneous hardware 
configurations, running a variety of variants of the Unix operating system, 
located in many countries around the world. This international network is 
known as Usenet. 

Systems participating in Usenet can connect with each other directly, using 
either a dedicated or a dial-up line, or they can communicate using other 
systems as relays (or hops). For example, I can send mail directly to a user 
at decuac by addressing the message to decuacluser , since my system hadron 
has a direct uucp link to decuac. If I want to send mail to a user at harvard , 
I would use a more extensive path, 

uunetUll-winkenluwvax! harvard! user 

where the / character in the address is used to separate the network names 
of each system, or hop, along the mail path. 
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One of the obvious problems with this type of network is determining a path 
to a given system, much less an optimum path. However, as with so many 
other potential problems in the Unix world, there is a user-developed 
solution. There is a Usenet map distributed on a nearly monthly basis to 
several systems in the United States, along with the pathalias software to 
compute optimized mail paths to the systems listed in the maps. The most 
recently distributed Usenet maps include Unix systems located in Austria, 
Belgium, Denmark, Finland, France, Greece, Iceland, Ireland, Italy, 
Luxenburg, Portugal, Spain, Sweden, Switzerland, The Netherlands, The 
United Kingdom, and West Germany as well as numerous sites in Asia and 
(of course) the United States. Although there is a designated coordinating 
site for each country, the maps themselves are available from several Usenet 
sites around the US. If you are a part of the uucp network, you can ask 
your site manager about mapping and path information. 

If you are not presently connected to either Usenet or the uusp network, you 
have 2 options, you can attempt to get connected to a system that is local to 
you, or you can establish an account with UUNET. UUNET is a non-profit 
communications service that provides access to USENET news, UUCP mail, 
and many standards (including the Internet RFCs and comp.std.unix 
archives). UUNET is the newest experimental project of the USENIX 
Association and has the unprecedented cooperation of DARPA. Without 
violating DECUS commercialism policies, I can state that the cost of using 
UUNET to access the Unix community is minimal. For additional 
information, you should contact 


Peter Sal us 
UUNET/USENIX 
P.O. Box 2299 
Berkeley, CA 94710 
415/528-8649 

(seismo, uunet, ucbvax ,cbosgd, ames, amdahl}! usenix! uunet-request 

Although net.news is sometimes referred to as a glorified bulletin board 
system, it is one of the most popular uses of Usenet. It permits an even more 
rapid exchange of information, because you do not need to know to whom to 
address your mail. All that is required (other than a connection or feed for 
the news) is to post a suitable message into the appropriate news group and 
in a short time the responses will come in, both in the news group and as 
direct mail. Of course, there will probably be as many different solutions to 
any given problem as there are people responding, but it is better then 
attempting to solve a problem in the dark. The news groups circulate 
messages, sources and some executables (converted to ascii representations 
using uuencode ) in a wide variety of technical and non-technical news 
groups. In a later column I will provide more information about net.news. 

In conclusion, there are many options available for use with a Unix system 
to provide networking capabilities and the distribution of resources. The 
inherent capabilities of the Unix uucp programs, and the resources provided 
by the uucp network provide enables unix systems that are a part of Usenet 
to be connected to a technical window on the world. 


UNI-8 



The Way It Is 
Warner/Davis 

Recently someone called me from one of the "Out on the Floor Offices", an 
ethereal place rumored to exist only in hyperspace, populated by mysterious 
beings called Users. 

She was quite frantic. She was having trouble running a program through 
the computer, and her message was clear enough, although rather ill- 
conceived: "MY FILES ARE FULL!" 

I furrowed my brow, lit a smoke, and explained to her, "Really now, Miss 
Butterman, I don’t have time for this." I slowly exhaled the menthol vapors 
as I stopped her process, crushing any hope she may have had of ever again 
seeing that document she had spent three hours slaving over. 

"I was typing this REALLY important letter, and it HAS to be ready 
in an hour... there’s all this stuff on my screen that I didn't type... it 
says something about an error, should I read it to you?" 

"No point. Just press return." 

"Oh my, it wants my username. Can I restart that where I left off?" 

"Not a chance." I drew another puff and tossed the phone aside. It 
occurred to me that if I had to hear one more of those whining com¬ 
plaint sessions, heads were gonna roll. Where do you people GET 
this stuff? I’m going to tell you what’s really going on here. Now 
LISTEN UP. I’m not going over this a second time: 


Computer 

The black box that does your work for you. That’s all you need to 
know. 


Response Time 

Usually measured in nanoseconds; sometimes measured in calendar 
months. The general rule is: Shut up your complaining about response 
time. 


Hardware 

See "Computer." Again, not your concern. 


Software 

If we want you to know, we’ll tell you about it, otherwise, leave us 
alone. 
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Network 

Don’t worry about it, we’ll take care of it. Use it to send mail among 
your half-wit selves, and don’t think we won’t read it all. What do you 
think we do all day? By the way, Butterman... shame about your 
mother’s pancreas. 


Data 

The general rule is: Don't use any data files and if you find any, delete 
them before I find out about them. In fact, just stay off the computer. 
(See "Response Time") 

System Crash 

Don’t ever call the system manager to tell him you think the computer 
is down. Don’t call him to ask him when it will be up again. The 
more you bother him, the longer it takes. 

Downtime 

Like I said, don’t ask. 

Uptime 

Be thankful for it, use it wisely, and get out of my face. 

Overtime 

Don’t be ridiculous. 

Vacation 

A time during which I don’t have to put up with your sniveling. Don’t 
try calling. There’s no point. 

Computer Room 

Keep out, you’re not invited. Don’t knock on the door - don’t even 
think about it. I broke the phone last time one of you jerks called me, 
and I’m not about to replace it. And keep your greasy fingers off the 
windows. 

My Office 

The name says it all... it’s mine; stay out. 

Your Problems 

Not my concern. 

Deadlines 

The general rule is: Deadlines are not acknowledged by me; they’re not 
my responsibility. Go tell somebody who cares. 
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Maintenance 

a) A Valid reason for shutting down the system at any time 

b) Much more important than anything any of you bozos do. 

c) Anything I choose to call maintenance. 

Software Upgrades 

Far too complex for you to comprehend. If I tell you I’m upgrading 
the system, just be quietly thankful. It’s for your own good, even if it 
does mean extensive downtime during peak hours. 

Electronic Mail 

I delete it before reading it, so don’t bother sending any to me. 

Defaults 

We like them just like they are; we chose them for a reason. Don’t 
mess with them; consider them mandatory. 

Error Messages 

I’m not interested. I’m going to kill your process anyway, so keep 
them to yourself. 

Killing your Process 

a) Don’t ever ask why 

b) Beyond your control 

c) No warnings given 

d) The highlight of my day 

e) If you call, it’s going to happen. No exceptions. 

Passwords 

I reserve the right to change them without notice at any time. I choose 
them, and the more you bother me, the more degrading yours will be. 
(Example: BUTTERMAN: SNOTFACE) 

Users 

a) They slow down the computer 

b) They waste my time 

c) A general nuisance 

d) Worse than that, actually 

Software Modifications 

You don’t know what you want - we'll tell you what you want. It stays 
like it is. Period. 

Privileges 

I’ve got them, you don't need them. Enough said. 
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Priority 

Mine is higher than yours, accept it. That's the reason my games run 
faster than your lousy accounting package. (See "Response Time") 

Terminals 

Before calling me with a terminal problem, consider this: 

a) Are you prepared to do without one for weeks? 

b) Do you REALLY want your process killed? 

c) Did you just trip over the cord again? 

d) Of course you did 

Disk Space 

I set the quotas, you live with them. If you need more space, check 
'Data Files". 

Operator 

I hired him and I trained him. He does what I tell him to. Usually 
armed; always dangerous. 

Backups 

a) A good idea 

b) If I gave a sh*t 

c) Which of course I don’t 

Lunch 

The only time that calling my office won’t result in the killing of your 
process. 

Data Security 

That’s your problem. I’m certainly not going to lose any sleep over it. 
My files are locked up tight. I feel secure. 

Jiffy Length of time it takes me to resolve your problem by killing your pro¬ 
cess. 


Eternity 

Length of time it takes me to give a sh*t about any problem that can’t 
be resolved by killing your process. 

Impossible 

a) It can’t be done (as far as you know) 

b) I can’t be bothered 

c) You’re starting to annoy me 
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Inevitable 

a) Couldn’t have been avoided 

b) Not my fault (as far as you know) 

c) The result of annoying me 

Menus 

If it’s not on the menu, don't ask for it. It’s not available. If it is on 
the menu, it’s probably of no use or it doesn't work. We’re working on 
it (See "Eternity"). 

Utilities 

I find them quite useful, you'll find them quite inaccessible. Besides, 
they’re not on your menu, are they. What did I tell you about that? 

Nuisance 

You. 

Of course, I reserve the right to add, change, or remove anything from the 
above list. I'm not asking you to accept these matters without question, I’m 
telling you. 

Now that we all know where we stand. I'm sure there’ll be no future prob¬ 
lems. If you have any questions or comments please feel free to keep them 
to yourself. If you feel the need for more information, I highly recommend 
that you ask someone else. 


Sincerely, 



System Manager 


P.S. The new disk quota of 30 blocks per user became effective yesterday. 
Anyone caught exceeding the quota will lose their accounts (this means 
you, Butterman!) 
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Contributions 


Contributions and suggestions for this newsletter are constantly needed. Articles, letters, 
technical tips, or anything of interest to our SIG are greatly appreciated. The editor prefers 
submissions be made electronically. Magnetic tape and hard copy will be accepted, but may 
delay publication. 

Please do not submit program source. It is difficult to typeset and is better distributed on 
the VAX SIG tape. Please do not submit “slides” from DECUS Symposia presentations or other 
meetings. They are generally a very incomplete treatment for those readers of the Pageswapper 
who are not so fortunate as to be able to travel to Symposia. Please DO write articles based on 
such slides. 

Send your contributions to: 

ARPAnet/CSnet/NSFnet: ctp@cs.utexas.edu 
UUCP: ctp@ut-sally.uucp ({harvard,ihnp4,uunet}!ut-sally!ctp) 

BITNET: CTP@UTADNX 
CompuServe: 75226,3135 
DCS: POOLE 


or if you must, use the U. S. Mails: 

Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin, Texas 78712-1188 


A New Hand at the Tiller 

David L. Wyse, VAX Systems SIG, Communications Committee Representative 


On behalf of the Executive Committee of the VAX Systems SIG, I would like to welcome 
the new editor of the Pageswapper , Clyde T. Poole. 

Clyde has had considerable experience with DECUS and has been the editor of At Large , 
the Large Systems SIG newsletter. Clyde is very active in the Communications Committee and 
we look forward to some stimulating issues of the Pageswapper. 

It will now be easier to submit to the Pageswapper. If you will take a look at the new 
“Contributions” article (above), you’ll see that Clyde has access to a host of networks and DCS. 
This should facilitate your contributions to your favorite newsletter. 

You should also have noticed one other change in the Pageswapper. Clyde will be type¬ 
setting the information sent to him so we should no longer have to turn the page around to read 
your favorite article. 
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Lastly, this note would not be complete without our sincere thanks to Larry Kilgallen 
for the countless hours spent in editing the Pageswapper, including shepherding our publication 
through the genesis and evolution of “The Big One”. Thanks Larry, from all of us. 


Spring 1988 SIR Ballot Results 

Mark Oakley, SIR Coordinator 


A total of 315 ballots were counted in the latest SIR ballot, a slight decline over the past 
two ballots. The number of ballots cast electronically on the Pageswapper VAX continues to 
increase. I want to thank Larry Kilgallen again for the use of this machine. 

There was a tie in the voting for tenth place between SIR S88-28 (improve VMS DEFINE 
utility) and SIR S88-11 (no CR/FL for DCL WRITE command). I have asked Digital to respond 
to both SIR’s. 

I am hopeful that participation will continue to build, and will look for ways to encourage 
you to vote. 

The SIR ballot is the only on-going program by which the SIG provides input to Digital. 
Top 10 (and other) SIR’s continue to be incorporated into VMS. Digital has repeatedly encouraged 
the use of this channel of communication. 

The summary of this voting appears below. Digital’s response to the top 11 requests overall 
will be presented at the Spring 1988 DECUS Symposium in Cincinnati. 

Interpreting the SIR Ballot Results 

The results of the System Improvement Request ballot are shown on the following pages. 
All of the reports have the same one page format. Following the report title is the number of 
ballots counted for that report. The number shown on the “All Users” report is the total number 
of ballots which were returned. The ballots on the “11/780 Users” report is the number of ballots 
which checked the “11/780” blank on the ballot questionnaire, and so on. 

The SIR’s axe listed on the page in order of points received, from highest to lowest. The 
entry for each SIR begins with the SIR number (from the ballot), a brief description, and the 
total number of votes (positive and negative) received by that SIR. 

The data is summarized in two different ways. First, there are a series of reports broken 
down by user category. The user categories are defined by the questionnaire portion of the SIR 
ballot. A ballot was counted in each user category which was checked off, for example “11/780 
user”. Finally, there are a series of reports ranking the SIR’s within SIR category. The SIR 
categories are those shown on the ballot, for example “DCL and Utilities” and “Commercial”. 
The reports by SIR category use the data from all ballots received. 


VAX-2 




Spring 1988 Ballot 

The Top 35 SIR's as Ranked by All Users 

Total ballots in this category: 315 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 120 

19 “Control Print Screen” capability 117 

37 Corrrect READALL behavior 115 

10 Various BACKUP enhancements 111 

23 Enhance SHOW PROCESS command 102 

3 Provide deallocation capability 97 

61 Enhance print form modules 94 

62 Provide BACKUP dismount/deallocate 94 

8 Provide queued ALLOCATE requests 91 

28 Improving VMS define utility 80 

11 No CR/LF for DCL WRITE command 80 

64 Provide limits on simultaneous logins 78 

14 Extend DCL TABLES 76 

42 Provide installed memory-resident code 75 

29 Provide $GETDVI “wild card” capability 74 

9 Provide project accounting 72 

20 Enhance sysgen parameter readability 72 

48 Prevent password reuse by users 69 

21 Provide Mail enhancements 67 

15 DCL status return enhancements 67 

68 Support multiple version products 64 

52 Security alarm messages to a file 60 

63 Support bell character in BACKUP 58 

6 Provide a “virtual disk” capability 54 

66 WSQUOTA/WSEXTENT for INSTALL 53 

49 Suppress certain login failures 52 

58 Provide RIGHTSLIST lexical function 52 

22 SET HOST/DTE for more modems 48 

54 Provide DECnet end-to-end encryption 47 

57 Enhance COPY to copy ACL’s 47 

2 Enhance batch load balancing 47 

30 Enhance $GETUAI and SSETUAI 44 

13 Enhanced command RECALL capabilities 44 

24 MOUNT/FOREIGN and uninitialized tapes 44 

1 Provide SCS communication services 43 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by VAX 8700/8800 

Total ballots in this category: 65 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 32 

37 Corrrect READ ALL behavior 28 

29 Provide $GETDVI “wild card” capability 25 

9 Provide project accounting 24 

48 Prevent password reuse by users 24 

52 Security alarm messages to a file 23 

23 Enhance SHOW PROCESS command 22 

8 Provide queued ALLOCATE requests 21 

19 “Control Print Screen” capability 19 

3 Provide deallocation capability 19 

20 Enhance sysgen parameter readability 18 

36 Provide descriptive text for files 17 

6 Provide a “virtual disk” capability 16 

61 Enhance print form modules 16 

54 Provide DECnet end-to-end encryption 15 

11 No CR/LF for DCL WRITE command 15 

62 Provide BACKUP dismount/deallocate 15 

51 Control file access via an image 14 

58 Provide RIGHTSLIST lexical function 14 

55 Support SET HOST proxy access 13 

64 Provide limits on simultaneous logins 13 

68 Support multiple version products 13 

15 DCL status return enhancements 12 

42 Provide installed memory-resident code 12 

30 Enhance SGETUAI and SSETUAI 12 

10 Various BACKUP enhancements 12 

1 Provide SCS communication services 11 

47 Eliminate unsolicited file creation ACE 11 

14 Extend DCL TABLES 11 

31 Improve terminal comm data display 11 

2 Enhance batch load balancing 11 

28 Improving VMS define utility 11 

57 Enhance COPY to copy ACL’s 10 

4 Improve tape label recognition 10 

49 Suppress certain login failures 10 
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Spring 1988 Ballot 

The Top 35 SIR's as Ranked by VAX 86nn 

Total ballots in this category: 111 


SIR SIR Total 

Nr. Description Votes 

8 Provide queued ALLOCATE requests 45 

37 Corrrect READALL behavior 43 

7 LAT sessions identity information 40 

29 Provide SGETDVI “wild card” capability 39 

52 Security alarm messages to a file 37 

19 “Control Print Screen” capability 36 

48 Prevent password reuse by users 36 

10 Various BACKUP enhancements 36 

23 Enhance SHOW PROCESS command 35 

14 Extend DCL TABLES 34 

42 Provide installed memory-resident code 34 

3 Provide deallocation capability 33 

68 Support multiple version products 31 

58 Provide RIGHTSLIST lexical function 28 

9 Provide project accounting 28 

61 Enhance print form modules 26 

15 DCL status return enhancements 25 

62 Provide BACKUP dismount/deallocate 24 

64 Provide limits on simultaneous logins 24 

11 No CR/LF for DCL WRITE command 24 

1 Provide SCS communication services 23 

57 Enhance COPY to copy ACL’s 22 

66 WSQUOTA/WSEXTENT for INSTALL 22 

20 Enhance sysgen parameter readability 22 

51 Control file access via an image 21 

2 Enhance batch load balancing 20 

28 Improving VMS define utility 18 

6 Provide a “virtual disk” capability 18 

13 Enhanced command RECALL capabilities 17 

31 Improve terminal comm data display 17 

54 Provide DECnet end-to-end encryption 16 

55 Support SET HOST proxy access 16 

21 Provide Mail enhancements 16 

60 Support ACE security alarm ACE bypass 15 

36 Provide descriptive text for files 15 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by VAX 85nn 

Total ballots in this category: 53 


SIR SIR Total 

Nr. Description Votes 

19 “Control Print Screen” capability 24 

7 LAT sessions identity information 23 

10 Various BACKUP enhancements 20 

8 Provide queued ALLOCATE requests 20 

23 Enhance SHOW PROCESS command 19 

11 No CR/LF for DCL WRITE command 18 

21 Provide Mail enhancements 15 

42 Provide installed memory-resident code 15 

9 Provide project accounting 14 

61 Enhance print form modules 13 

28 Improving VMS define utility 12 

15 DCL status return enhancements 12 

1 Provide SCS communication services 12 

62 Provide BACKUP dismount/deallocate 12 

37 Corrrect READ ALL behavior 11 

13 Enhanced command RECALL capabilities 11 

49 Suppress certain login failures 11 

54 Provide DECnet end-to-end encryption 11 

3 Provide deallocation capability 11 

2 Enhance batch load balancing 11 

47 Eliminate unsolicited file creation ACE 10 

48 Prevent password reuse by users 10 

36 Provide descriptive text for files 10 

68 Support multiple version products 10 

29 Provide SGETDVI “wild card” capability 9 

52 Security alarm messages to a file 9 

64 Provide limits on simultaneous logins 9 

14 Extend DCL TABLES 9 

6 Provide a “virtual disk” capability 8 

53 Provide ACL class names management 8 

31 Improve terminal comm data display 8 

66 WSQUOTA/WSEXTENT for INSTALL 8 

56 Improve DECnet file access control 8 

26 Support DCL command /BELL qualifier 7 

25 Enhanced DEFINE/KEY capabilities 7 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by VAX 83nn/82nn 

Total ballots in this category: 87 


SIR 

SIR 

Total 

Nr. 

Description 

Votes 

7 

LAT sessions identity information 

45 

10 

Various BACKUP enhancements 

32 

37 

Corrrect READALL behavior 

32 

19 

“Control Print Screen” capability 

31 

9 

Provide project accounting 

29 

23 

Enhance SHOW PROCESS command 

28 

11 

No CR/LF for DCL WRITE command 

26 

3 

Provide deallocation capability 

26 

61 

Enhance print form modules 

26 

62 

Provide BACKUP dismount/deallocate 

25 

8 

Provide queued ALLOCATE requests 

21 

48 

Prevent password reuse by users 

21 

64 

Provide limits on simultaneous logins 

20 

36 

Provide descriptive text for files 

19 

21 

Provide Mail enhancements 

19 

15 

DCL status return enhancements 

19 

2 

Enhance batch load balancing 

18 

20 

Enhance sysgen parameter readability 

18 

63 

Support bell character in BACKUP 

18 

29 

Provide SGETDVI “wild card” capability 

18 

42 

Provide installed memory-resident code 

17 

49 

Suppress certain login failures 

17 

1 

Provide SCS communication services 

16 

47 

Eliminate unsolicited file creation ACE 

16 

22 

SET HOST/DTE for more modems 

15 

54 

Provide DECnet end-to-end encryption 

15 

55 

Support SET HOST proxy access 

15 

6 

Provide a “virtual disk” capability 

15 

28 

Improving VMS define utility 

15 

13 

Enhanced command RECALL capabilities 

15 

30 

Enhance SGETUAI and SSETUAI 

15 

66 

WSQUOTA/WSEXTENT for INSTALL 

15 

52 

Security alarm messages to a file 

13 

58 

Provide RIGHTSLIST lexical function 

12 

14 

Extend DCL TABLES 

12 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by VAX 11/780, 11/782, 11/785 

Total ballots in this category: 196 


SIR SIR Total 

Nr. Description Votes 

37 Corrrect READALL behavior 77 

10 Various BACKUP enhancements 72 

7 LAT sessions identity information 72 

19 “Control Print Screen” capability 71 

8 Provide queued ALLOCATE requests 68 

3 Provide deallocation capability 66 

23 Enhance SHOW PROCESS command 61 

62 Provide BACKUP dismount/deallocate 57 

29 Provide SGETDVI “wild card” capability 55 

61 Enhance print form modules 54 

14 Extend DCL TABLES 53 

48 Prevent password reuse by users 53 

52 Security alarm messages to a file 51 

9 Provide project accounting 48 

42 Provide installed memory-resident code 48 

11 No CR/LF for DCL WRITE command 48 

68 Support multiple version products 47 

64 Provide limits on simultaneous logins 46 

28 Improving VMS define utility 46 

20 Enhance sysgen parameter readability 40 

58 Provide RIGHTSLIST lexical function 40 

15 DCL status return enhancements 38 

54 Provide DECnet end-to-end encryption 36 

21 Provide Mail enhancements 36 

13 Enhanced command RECALL capabilities 34 

6 Provide a “virtual disk” capability 33 

66 WSQUOTA/WSEXTENT for INSTALL 32 

63 Support bell character in BACKUP 32 

30 Enhance SGETUAI and $SETUAI 31 

49 Suppress certain login failures 30 

57 Enhance COPY to copy ACL’s 30 

2 Enhance batch load balancing 30 

1 Provide SCS communication services 29 

51 Control file access via an image 29 

25 Enhanced DEFINE/KEY capabilities 28 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by VAX 11/750 

Total ballots in this category: 137 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 51 

19 “Control Print Screen” capability 50 

37 Corrrect READALL behavior 46 

10 Various BACKUP enhancements 43 

61 Enhance print form modules 43 

23 Enhance SHOW PROCESS command 42 

8 Provide queued ALLOCATE requests 40 

3 Provide deallocation capability 39 

11 No CR/LF for DCL WRITE command 39 

62 Provide BACKUP dismount/deallocate 37 

28 Improving VMS define utility 36 

15 DCL status return enhancements 36 

42 Provide installed memory-resident code 34 

9 Provide project accounting 33 

20 Enhance sysgen parameter readability 31 

64 Provide limits on simultaneous logins 31 

29 Provide SGETDVI “wild card” capability 29 

63 Support bell character in BACKUP 27 

1 Provide SCS communication services 26 

48 Prevent password reuse by users 26 

21 Provide Mail enhancements 26 

55 Support SET HOST proxy access 24 

68 Support multiple version products 24 

66 WSQUOTA/WSEXTENT for INSTALL 23 

6 Provide a “virtual disk” capability 23 

18 Make DCL /LOG qualifier consistent 21 

14 Extend DCL TABLES 20 

58 Provide RIGHTSLIST lexical function 20 

24 MOUNT/FOREIGN and uninitialized tapes 20 

67 Priority for INSTALL 20 

31 Improve terminal comm data display 20 

50 No file update when protections change 19 

47 Eliminate unsolicited file creation ACE 19 

36 Provide descriptive text for files 18 

46 Provide line-number support in TPU 18 
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Spring 1988 Ballot 

The Top 35 SIR's as Ranked by VAX 11/730, 11/725 

Total ballots in this category: 57 

SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 24 

37 Corrrect READALL behavior 22 

19 “Control Print Screen” capability 21 

8 Provide queued ALLOCATE requests 20 

61 Enhance print form modules 19 

28 Improving VMS define utility 15 

15 DCL status return enhancements 15 

3 Provide deallocation capability 15 

10 Various BACKUP enhancements 14 

62 Provide BACKUP dismount/deallocate 14 

66 WSQUOTA/WSEXTENT for INSTALL 14 

68 Support multiple version products 14 

1 Provide SCS communication services 13 

23 Enhance SHOW PROCESS command 12 

42 Provide installed memory-resident code 12 

11 No CR/LF for DCL WRITE command 12 

29 Provide $GETDVI “wild card” capability 11 

67 Priority for INSTALL 11 

36 Provide descriptive text for files 11 

31 Improve terminal comm data display 10 

9 Provide project accounting 10 

64 Provide limits on simultaneous logins 10 

13 Enhanced command RECALL capabilities 9 

52 Security alarm messages to a file 9 

56 Improve DECnet file access control 9 

58 Provide RIGHTSLIST lexical function 9 

14 Extend DCL TABLES 9 

49 Suppress certain login failures 8 

21 Provide Mail enhancements 8 

54 Provide DECnet end-to-end encryption 8 

55 Support SET HOST proxy access 8 

2 Enhance batch load balancing 8 

25 Enhanced DEFINE/KEY capabilities 8 

24 MOUNT/FOREIGN and uninitialized tapes 7 

20 Enhance sysgen parameter readability 7 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Micro VAX I, II 

Total ballots in this category: 218 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 83 

19 “Control Print Screen” capability 75 

8 Provide queued ALLOCATE requests 74 

10 Various BACKUP enhancements 73 

3 Provide deallocation capability 73 

23 Enhance SHOW PROCESS command 72 

37 Corrrect READALL behavior 72 

61 Enhance print form modules 68 

29 Provide $GETDVI “wild card” capability 62 

48 Prevent password reuse by users 56 

42 Provide installed memory-resident code 54 

11 No CR/LF for DCL WRITE command 53 

62 Provide BACKUP dismount/deallocate 53 

14 Extend DCL TABLES 51 

9 Provide project accounting 50 

28 Improving VMS define utility 50 

20 Enhance sysgen parameter readability 46 

64 Provide limits on simultaneous logins 45 

52 Security alarm messages to a file 44 

15 DCL status return enhancements 44 

68 Support multiple version products 43 

58 Provide RIGHTSLIST lexical function 41 

6 Provide a “virtual disk” capability 40 

21 Provide Mail enhancements 39 

2 Enhance batch load balancing 38 

57 Enhance COPY to copy ACL’s 37 

1 Provide SCS communication services 35 

55 Support SET HOST proxy access 34 

13 Enhanced command RECALL capabilities 32 

63 Support bell character in BACKUP 32 

54 Provide DECnet end-to-end encryption 32 

66 WSQUOTA/WSEXTENT for INSTALL 32 

49 Suppress certain login failures 32 

36 Provide descriptive text for files 31 

24 MOUNT/FOREIGN and uninitialized tapes 30 
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Spring 1988 Ballot 

The Top 35 SIR's as Ranked by MicroVAX 2000 

Total ballots in this category: 64 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 30 

8 Provide queued ALLOCATE requests 25 

23 Enhance SHOW PROCESS command 24 

37 Corrrect READALL behavior 23 

19 “Control Print Screen” capability 22 

28 Improving VMS define utility 21 

10 Various BACKUP enhancements 19 

3 Provide deallocation capability 18 

11 No CR/LF for DCL WRITE command 18 

9 Provide project accounting 18 

48 Prevent password reuse by users 18 

15 DCL status return enhancements 16 

29 Provide SGETDVI “wild card” capability 14 

36 Provide descriptive text for files 14 

6 Provide a “virtual disk” capability 14 

20 Enhance sysgen parameter readability 14 

52 Security alarm messages to a file 14 

55 Support SET HOST proxy access 14 

61 Enhance print form modules 14 

62 Provide BACKUP dismount/deallocate 14 

1 Provide SCS communication services 13 

21 Provide Mail enhancements 13 

14 Extend DCL TABLES 13 

42 Provide installed memory-resident code 12 

58 Provide RIGHTSLIST lexical function 12 

68 Support multiple version products 12 

54 Provide DECnet end-to-end encryption 11 

31 Improve terminal comm data display 11 

51 Control file access via an image 10 

66 WSQUOTA/WSEXTENT for INSTALL 10 

2 Enhance batch load balancing 10 

22 SET HOST/DTE for more modems 9 

13 Enhanced command RECALL capabilities 9 

64 Provide limits on simultaneous logins 9 

49 Suppress certain login failures 9 


VAX-12 



Spring 1988 Ballot 

The Top 35 SIR's as Ranked by Micro VAX 3n00 

Total ballots in this category: 17 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 9 

37 Corrrect READALL behavior 8 

3 Provide deallocation capability 7 

19 “Control Print Screen” capability 7 

6 Provide a “virtual disk” capability 7 

48 Prevent password reuse by users 6 

52 Security alarm messages to a file 6 

61 Enhance print form modules 6 

64 Provide limits on simultaneous logins 6 

8 Provide queued ALLOCATE requests 5 

9 Provide project accounting 5 

2 Enhance batch load balancing 5 

21 Provide Mail enhancements 5 

22 SET HOST/DTE for more modems 5 

47 Eliminate unsolicited file creation ACE 4 

11 No CR/LF for DCL WRITE command 4 

10 Various BACKUP enhancements 4 

54 Provide DECnet end-to-end encryption 4 

58 Provide RIGHTSLIST lexical function 4 

28 Improving VMS define utility 4 

62 Provide BACKUP dismount/deallocate 4 

20 Enhance sysgen parameter readability 4 

49 Suppress certain login failures 3 

13 Enhanced command RECALL capabilities 3 

29 Provide $GETDVI “wild card” capability 3 

15 DCL status return enhancements 3 

45 VAX ADA needs complete VMS RTL package 3 

1 Provide SCS communication services 3 

63 Support bell character in BACKUP 3 

23 Enhance SHOW PROCESS command 3 

68 Support multiple version products 3 

43 Provide /NOWAIT switch for TPU 2 

57 Enhance COPY to copy ACL’s 2 

26 Support DCL command /BELL qualifier 2 

31 Improve terminal comm data display 2 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Business EDP 

Total ballots in this category: 116 


SIR SIR Total 

Nr. Description Votes 

LAT sessions identity information 53 

Various BACKUP enhancements 50 

Enhance print form modules 43 

Corrrect READALL behavior 42 

Enhance SHOW PROCESS command 40 

Provide SGETDVI “wild card” capability 40 

Prevent password reuse by users 39 

“Control Print Screen” capability 37 

Provide deallocation capability 35 

Support multiple version products 33 

Extend DCL TABLES 32 

Provide BACKUP dismount/deallocate 31 

Provide installed memory-resident code 31 

Provide RIGHTSLIST lexical function 30 

Provide queued ALLOCATE requests 29 

Provide project accounting 26 

Support bell character in BACKUP 26 

Provide limits on simultaneous logins 26 

Security alarm messages to a file 26 

No CR/LF for DCL WRITE command 25 

SET HOST/DTE for more modems 25 

Improving VMS define utility 24 

Enhance COPY to copy ACL’s 24 

Support SET HOST proxy access 22 

Provide a “virtual disk” capability 22 

Suppress certain login failures 22 

Enhance sysgen parameter readability 22 

Provide Mail enhancements 21 

WSQUOTA/WSEXTENT for INSTALL 20 

DCL status return enhancements 20 

Provide DECnet end-to-end encryption 19 

Provide descriptive text for files 18 

Enhance batch load balancing 17 

Control file access via an image 16 

Improve terminal comm data display 16 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Education 

Total ballots in this category: 53 


SIR SIR Total 

Nr. Description Votes 

37 Corrrect READALL behavior 27 

19 “Control Print Screen” capability 26 

10 Various BACKUP enhancements 24 

7 LAT sessions identity information 20 

62 Provide BACKUP dismount/deallocate 20 

64 Provide limits on simultaneous logins 20 

30 Enhance SGETUAI and SSETUAI 18 

28 Improving VMS define utility 17 

23 Enhance SHOW PROCESS command 16 

11 No CR/LF for DCL WRITE command 16 

21 Provide Mail enhancements 16 

66 WSQUOTA/WSEXTENT for INSTALL 16 

14 Extend DCL TABLES 15 

20 Enhance sysgen parameter readability 15 

61 Enhance print form modules 14 

52 Security alarm messages to a file 13 

54 Provide DECnet end-to-end encryption 13 

51 Control file access via an image 12 

15 DCL status return enhancements 11 

22 SET HOST/DTE for more modems 11 

49 Suppress certain login failures 11 

9 Provide project accounting 11 

8 Provide queued ALLOCATE requests 11 

67 Priority for INSTALL 11 

68 Support multiple version products 11 

57 Enhance COPY to copy ACL’s 10 

42 Provide installed memory-resident code 10 

65 Provide UAF distributed management 10 

63 Support bell character in BACKUP 9 

31 Improve terminal comm data display 9 

3 Provide deallocation capability 9 

55 Support SET HOST proxy access 8 

18 Make DCL /LOG qualifier consistent 8 

32 Provide directory file enhancements 8 

29 Provide $GETDVI “wild card” capability 8 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Data Acquisition/Control 

Total ballots in this category: 65 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 29 

37 Corrrect READALL behavior 29 

23 Enhance SHOW PROCESS command 24 

11 No CR/LF for DCL WRITE command 23 

19 “Control Print Screen” capability 23 

28 Improving VMS define utility 20 

8 Provide queued ALLOCATE requests 20 

20 Enhance sysgen parameter readability 19 

3 Provide deallocation capability 19 

42 Provide installed memory-resident code 19 

62 Provide BACKUP dismount/deallocate 19 

61 Enhance print form modules 18 

31 Improve terminal comm data display 18 

10 Various BACKUP enhancements 17 

15 DCL status return enhancements 15 

14 Extend DCL TABLES 15 

64 Provide limits on simultaneous logins 15 

48 Prevent password reuse by users 14 

55 Support SET HOST proxy access 13 

29 Provide SGETDVI “wild card” capability 13 

6 Provide a “virtual disk” capability 13 

36 Provide descriptive text for files 13 

9 Provide project accounting 12 

68 Support multiple version products 12 

66 WSQUOTA/WSEXTENT for INSTALL 11 

18 Make DCL /LOG qualifier consistent 11 

21 Provide Mail enhancements 10 

57 Enhance COPY to copy ACL’s 9 

58 Provide RIGHTSLIST lexical function 9 

2 Enhance batch load balancing 9 

51 Control file access via an image 9 

53 Provide ACL class names management 9 

54 Provide DECnet end-to-end encryption 9 

47 Eliminate unsolicited file creation ACE 9 

13 Enhanced command RECALL capabilities 8 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Service Bureau 

Total ballots in this category: 23 


SIR SIR Total 

Nr. Description Votes 

8 Provide queued ALLOCATE requests 11 

10 Various BACKUP enhancements 10 

14 Extend DCL TABLES 8 

37 Corrrect READALL behavior 8 

23 Enhance SHOW PROCESS command 7 

31 Improve terminal comm data display 7 

36 Provide descriptive text for files 7 

7 LAT sessions identity information 7 

68 Support multiple version products 7 

21 Provide Mail enhancements 6 

13 Enhanced command RECALL capabilities 6 

52 Security alarm messages to a file 6 

55 Support SET HOST proxy access 6 

11 No CR/LF for DCL WRITE command 6 

38 Support image backward compatibility 5 

39 Enhance DYNSWITCH software 5 

47 Eliminate unsolicited file creation ACE 5 

6 Provide a “virtual disk” capability 5 

19 “Control Print Screen” capability 5 

58 Provide RIGHTSLIST lexical function 5 

61 Enhance print form modules 5 

62 Provide BACKUP dismount/deallocate 5 

65 Provide UAF distributed management 5 

29 Provide SGETDVI “wild card” capability 5 

28 Improving VMS define utility 4 

42 Provide installed memory-resident code 4 

15 DCL status return enhancements 4 

48 Prevent password reuse by users 4 

64 Provide limits on simultaneous logins 4 

9 Provide project accounting 4 

54 Provide DECnet end-to-end encryption 4 

44 Multiple “.END” statements in Macro 3 

2 Enhance batch load balancing 3 

3 Provide deallocation capability 3 

51 Control file access via an image 3 
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Spring 1988 Ballot 

The Top 35 SIR’S as Ranked by Scientific/Engineering 

Total ballots in this category: 194 

SIR SIR Total 

Nr. Description Votes 

37 Corrrect READALL behavior 76 

8 Provide queued ALLOCATE requests 71 

3 Provide deallocation capability 71 

19 “Control Print Screen” capability 69 

7 LAT sessions identity information 62 

10 Various BACKUP enhancements 62 

23 Enhance SHOW PROCESS command 59 

61 Enhance print form modules 59 

62 Provide BACKUP dismount/deallocate 57 

29 Provide SGETDVI “wild card” capability 49 

9 Provide project accounting 48 

14 Extend DCL TABLES 47 

11 No CR/LF for DCL WRITE command 46 

28 Improving VMS define utility 46 

42 Provide installed memory-resident code 44 

52 Security alarm messages to a file 44 

20 Enhance sysgen parameter readability 43 

68 Support multiple version products 43 

48 Prevent password reuse by users 42 

64 Provide limits on simultaneous logins 38 

15 DCL status return enhancements 38 

57 Enhance COPY to copy ACL’s 36 

58 Provide RIGHTSLIST lexical function 35 

21 Provide Mail enhancements 34 

63 Support bell character in BACKUP 33 

2 Enhance batch load balancing 29 

49 Suppress certain login failures 29 

66 WSQUOTA/WSEXTENT for INSTALL 28 

47 Eliminate unsolicited file creation ACE 27 

13 Enhanced command RECALL capabilities 27 

24 MOUNT/FOREIGN and uninitialized tapes 27 

6 Provide a “virtual disk” capability 25 

1 Provide SCS communication services 25 

36 Provide descriptive text for files 24 

55 Support SET HOST proxy access 24 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Telecommunications 

Total ballots in this category: 93 


SIR SIR Total 

Nr. Description Votes 

8 Provide queued ALLOCATE requests 40 

10 Various BACKUP enhancements 36 

3 Provide deallocation capability 35 

7 LAT sessions identity information 33 

42 Provide installed memory-resident code 33 

52 Security alarm messages to a file 31 

37 Corrrect READALL behavior 30 

19 “Control Print Screen” capability 29 

61 Enhance print form modules 28 

48 Prevent password reuse by users 27 

58 Provide RIGHTSLIST lexical function 26 

29 Provide $GETDVI “wild card” capability 26 

14 Extend DCL TABLES 25 

9 Provide project accounting 23 

68 Support multiple version products 23 

11 No CR/LF for DCL WRITE command 22 

28 Improving VMS define utility 22 

23 Enhance SHOW PROCESS command 21 

62 Provide BACKUP dismount/deallocate 19 

15 DCL status return enhancements 18 

57 Enhance COPY to copy ACL’s 18 

60 Support ACE security alarm ACE bypass 17 

6 Provide a “virtual disk” capability 17 

13 Enhanced command RECALL capabilities 16 

20 Enhance sysgen parameter readability 15 

2 Enhance batch load balancing 15 

54 Provide DECnet end-to-end encryption 15 

55 Support SET HOST proxy access 15 

64 Provide limits on simultaneous logins 15 

1 Provide SCS communication services 15 

70 Enhance BACKUP file attribute 15 

21 Provide Mail enhancements 13 

36 Provide descriptive text for files 13 

31 Improve terminal comm data display 12 

66 WSQUOTA/WSEXTENT for INSTALL 12 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Software Development 

Total ballots in this category: 238 


SIR SIR Total 

Nr. Description Votes 

37 Corrrect READALL behavior 90 

7 LAT sessions identity information 86 

23 Enhance SHOW PROCESS command 79 

10 Various BACKUP enhancements 79 

19 “Control Print Screen” capability 78 

3 Provide deallocation capability 77 

61 Enhance print form modules 77 

8 Provide queued ALLOCATE requests 75 

11 No CR/LF for DCL WRITE command 63 

29 Provide SGETDVI “wild card” capability 63 

9 Provide project accounting 60 

14 Extend DCL TABLES 59 

62 Provide BACKUP dismount/deallocate 59 

42 Provide installed memory-resident code 58 

15 DCL status return enhancements 54 

48 Prevent password reuse by users 53 

64 Provide limits on simultaneous logins 52 

28 Improving VMS define utility 51 

20 Enhance sysgen parameter readability 50 

52 Security alarm messages to a file 47 

21 Provide Mail enhancements 47 

68 Support multiple version products 47 

58 Provide RIGHTSLIST lexical function 42 

57 Enhance COPY to copy ACL’s 41 

6 Provide a “virtual disk” capability 39 

63 Support bell character in BACKUP 39 

54 Provide DECnet end-to-end encryption 38 

66 WSQUOTA/WSEXTENT for INSTALL 38 

2 Enhance batch load balancing 38 

13 Enhanced command RECALL capabilities 36 

1 Provide SCS communication services 36 

31 Improve terminal comm data display 34 

30 Enhance $GETUAI and SSETUAI 33 

55 Support SET HOST proxy access 33 

22 SET HOST/DTE for more modems 32 


VAX-20 



Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Computer Science Research 

Total ballots in this category: 31 


SIR SIR Total 

Nr. Description Votes 

37 Corrrect READALL behavior 14 

9 Provide project accounting 13 

48 Prevent password reuse by users 12 

7 LAT sessions identity information 11 

19 “Control Print Screen” capability 11 

28 Improving VMS define utility 9 

3 Provide deallocation capability 9 

23 Enhance SHOW PROCESS command 9 

62 Provide BACKUP dismount/deallocate 9 

8 Provide queued ALLOCATE requests 8 

6 Provide a “virtual disk” capability 8 

10 Various BACKUP enhancements 8 

68 Support multiple version products 8 

14 Extend DCL TABLES 7 

54 Provide DECnet end-to-end encryption 7 

52 Security alarm messages to a file 6 

11 No CR/LF for DCL WRITE command 6 

55 Support SET HOST proxy access 6 

31 Improve terminal comm data display 6 

49 Suppress certain login failures 6 

24 MOUNT/FOREIGN and uninitialized tapes 5 

27 Restore CONTROLJJ behavior 5 

1 Provide SCS communication services 5 

20 Enhance sysgen parameter readability 5 

2 Enhance batch load balancing 5 

56 Improve DECnet file access control 5 

58 Provide RIGHTSLIST lexical function 5 

61 Enhance print form modules 5 

42 Provide installed memory-resident code 5 

47 Eliminate unsolicited file creation ACE 5 

15 DCL status return enhancements 4 

21 Provide Mail enhancements 4 

18 Make DCL /LOG qualifier consistent 4 

35 Priority control of DECnet processes 4 

36 Provide descriptive text for files 4 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by CAD/CAM 

Total ballots in this category: 87 


SIR SIR Total 

Nr. Description Votes 

3 Provide deallocation capability 38 

8 Provide queued ALLOCATE requests 36 

10 Various BACKUP enhancements 36 

19 “Control Print Screen” capability 33 

61 Enhance print form modules 32 

48 Prevent password reuse by users 31 

37 Corrrect READALL behavior 30 

29 Provide SGETDVI “wild card” capability 29 

7 LAT sessions identity information 29 

68 Support multiple version products 28 

62 Provide BACKUP dismount/deallocate 26 

42 Provide installed memory-resident code 26 

23 Enhance SHOW PROCESS command 24 

11 No CR/LF for DCL WRITE command 24 

9 Provide project accounting 23 

14 Extend DCL TABLES 23 

52 Security alarm messages to a file 23 

58 Provide RIGHTSLIST lexical function 22 

28 Improving VMS define utility 19 

15 DCL status return enhancements 19 

57 Enhance COPY to copy ACL’s 16 

49 Suppress certain login failures 15 

70 Enhance BACKUP file attribute 15 

54 Provide DECnet end-to-end encryption 13 

63 Support bell character in BACKUP 13 

47 Eliminate unsolicited file creation ACE 12 

6 Provide a “virtual disk” capability 12 

60 Support ACE security alarm ACE bypass 11 

46 Provide line-number support in TPU 11 

1 Provide SCS communication services 10 

64 Provide limits on simultaneous logins 10 

31 Improve terminal comm data display 10 

20 Enhance sysgen parameter readability 10 

2 Enhance batch load balancing 9 

18 Make DCL /LOG qualifier consistent 9 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Hardware Development 

Total ballots in this category: 33 


SIR SIR Total 

Nr. Description Votes 

3 Provide deallocation capability 12 

8 Provide queued ALLOCATE requests 12 

19 “Control Print Screen” capability 12 

37 Corrrect READALL behavior 12 

7 LAT sessions identity information 11 

10 Various BACKUP enhancements 11 

61 Enhance print form modules 11 

9 Provide project accounting 9 

62 Provide BACKUP dismount/deallocate 9 

42 Provide installed memory-resident code 8 

1 Provide SCS communication services 8 

15 DCL status return enhancements 8 

11 No CR/LF for DCL WRITE command 7 

23 Enhance SHOW PROCESS command 7 

2 Enhance batch load balancing 7 

66 WSQUOTA/WSEXTENT for INSTALL 7 

68 Support multiple version products 7 

21 Provide Mail enhancements 6 

29 Provide SGETDVI “wild card” capability 6 

47 Eliminate unsolicited file creation ACE 6 

49 Suppress certain login failures 6 

5 Providing batch job “filtering” 5 

20 Enhance sysgen parameter readability 5 

14 Extend DCL TABLES 5 

6 Provide a “virtual disk” capability 5 

54 Provide DECnet end-to-end encryption 5 

28 Improving VMS define utility 5 

18 Make DCL /LOG qualifier consistent 5 

64 Provide limits on simultaneous logins 5 

33 Provide a real-time debugger 5 

36 Provide descriptive text for files 5 

58 Provide RIGHTSLIST lexical function 4 

46 Provide line-number support in TPU 4 

31 Improve terminal comm data display 4 

63 Support bell character in BACKUP 4 


VAX-23 



Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Office Automation 

Total ballots in this category: 145 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 64 

10 Various BACKUP enhancements 60 

37 Corrrect READALL behavior 55 

61 Enhance print form modules 55 

3 Provide deallocation capability 49 

48 Prevent password reuse by users 48 

42 Provide installed memory-resident code 47 

19 “Control Print Screen” capability 45 

23 Enhance SHOW PROCESS command 45 

8 Provide queued ALLOCATE requests 44 

29 Provide SGETDVI “wild card” capability 42 

11 No CR/LF for DCL WRITE command 38 

62 Provide BACKUP dismount/deallocate 38 

14 Extend DCL TABLES 37 

68 Support multiple version products 35 

58 Provide RIGHTSLIST lexical function 34 

52 Security alarm messages to a file 34 

9 Provide project accounting 31 

20 Enhance sysgen parameter readability 31 

64 Provide limits on simultaneous logins 30 

15 DCL status return enhancements 30 

54 Provide DECnet end-to-end encryption 29 

28 Improving VMS define utility 29 

55 Support SET HOST proxy access 27 

22 SET HOST/DTE for more modems 27 

36 Provide descriptive text for files 26 

66 WSQUOTA/WSEXTENT for INSTALL 25 

57 Enhance COPY to copy ACL’s 25 

49 Suppress certain login failures 24 

6 Provide a “virtual disk” capability 23 

63 Support bell character in BACKUP 22 

21 Provide Mail enhancements 22 

51 Control file access via an image 21 

31 Improve terminal comm data display 21 

25 Enhanced DEFINE/KEY capabilities 21 
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Spring 1988 Ballot 

The Top 35 SIR’s as Ranked by Other 

Total ballots in this category: 21 


SIR SIR Total 

Nr. Description Votes 

7 LAT sessions identity information 11 

20 Enhance sysgen parameter readability 9 

23 Enhance SHOW PROCESS command 9 

28 Improving VMS define utility 9 

37 Corrrect READALL behavior 9 

21 Provide Mail enhancements 7 

15 DCL status return enhancements 7 

19 “Control Print Screen” capability 7 

6 Provide a “virtual disk” capability 7 

62 Provide BACKUP dismount/deallocate 7 

64 Provide limits on simultaneous logins 7 

67 Priority for INSTALL 7 

10 Various BACKUP enhancements 6 

1 Provide SCS communication services 6 

42 Provide installed memory-resident code 6 

68 Support multiple version products 6 

48 Prevent password reuse by users 5 

61 Enhance print form modules 5 

3 Provide deallocation capability 5 

63 Support bell character in BACKUP 5 

29 Provide SGETDVI “wild card” capability 5 

8 Provide queued ALLOCATE requests 5 

24 MOUNT/FOREIGN and uninitialized tapes 5 

11 No CR/LF for DCL WRITE command 4 

18 Make DCL /LOG qualifier consistent 4 

54 Provide DECnet end-to-end encryption 4 

26 Support DCL command /BELL qualifier 3 

2 Enhance batch load balancing 3 

56 Improve DECnet file access control 3 

22 SET HOST/DTE for more modems 3 

36 Provide descriptive text for files 3 

14 Extend DCL TABLES 3 

5 Providing batch job “filtering” 3 

43 Provide /NOWAIT switch for TPU 3 

46 Provide line-number support in TPU 3 
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It’s On The Tapes 

Glenn Everhart 


Did you ever wish you had a VAXstation on your desk instead of a VT100 or VT200? Ever 
feel that you could be more productive with lots of windows and processes so you could avoid 
waiting for the VAX to get finished with something? 

Well, you can (almost). 

A VT terminal usually has too few characters to be usefully split up, and applications 
that run multiple processes through windows on a VT (using SMG$ or the like) are CPU hogs. 
However, software that can let you use the whole VT screen as a window exists. It’s called BOSS 
and a version can be found in the [vax87d.rcaf87.netnew] directory. This is a program written 
by Charles Karney and released via the ARPAnet. It uses the pseudo terminal driver submitted 
to the tapes by Kevin Carosso and allows you to manage up to 8 subprocesses at a time, switching 
dynamically between them via a “hotkey”. Its system overhead is negligible and it can swap out 
of a process at any time. Because it uses the PY/TP driver combination, the applications are 
running at real terminal devices, so they all act normally. Also, one can spawn a new process (if 
one hasn’t used all available) at any time without disturbing the context. 

Full screen applications are generally able to repaint the screen, so BOSS does nothing 
to keep track of what’s on any screen. You do lose the contents of a screen in non-full screen 
applications, as they scroll off screen, but this generally presents few problems. 

A new version, which should be on the Spring ’88 tape, has been released which buffers 
output from the hidden processes and displays it when you bring up their windows. This is very 
handy for many applications. 

The F87 version of BOSS introduced the ability of one process to send controlling input 
to another too. With a little work, this can be used to create a hypertext system, with the 
restriction that only one “box” can be displayed at a time. The random connections between 
“boxes” (where a box is implemented as one of the subprocesses, and another “master” subprocess 
has the program that fires up the commands to move from one subprocess to another) can be 
implemented using fairly crude techniques. It takes only the will to build it and a use for it. 

To use such a system, you’d get into a “master” process to bring up the “window” of 
what to link to. The master process would allow selection of one of several possible commands 
to be sent to a “slave” process (e.g. to edit text or pictures) by accessing some data base or 
data file based on the “current” (or last) subordinate command selected. One possible command 
might result in editing the list of commands at any point in the database, allowing links between 
subordinate commands to be modified. The master process could then, via the good offices of 
BOSS, send the command to another BOSS subprocess and thus run any desired command. Full 
screen applications would present no problems this way, as they might where mailboxes were 
used. Also, more elaborate implementations that permitted several open applications could be 
devised. 

BOSS is an enabling technology for terminal users which has abilities that should not be 
overlooked. I recommend that if you use a VT terminal, you look it over. 


( 
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VAX/VMS Security 
One in a Series 

Ray Kaplan, PIVOTAL, Inc., Tucson, AZ 


On Hackers 

The usage of the term “hacker” has changed over the last few years. Of late, the term 
“hacker” has come to mean what I consider to be a “computer criminal” in its current common 
use by the lay public and press. Even the current trade press abuses the term. 

By some definitions, a hacker is the ultimate expert programmer of days of old when 
memory, disk and CPU cycles were very scarce. A hacker could produce a most beautiful and 
elegant solution to a problem in a very few lines of code. By some definitions, a hacker is a 
consummate programmer that can completely exploit their machine resources so well that they 
end up with absolutely no extraneous code and a problem solution that is perfectly tight and 
elegant. And, by some definitions, a hacker is anyone that “plays” at anything that they do. You 
know, folks that hack at golf, tennis, flying or whatever their interests are! All I know is that I 
must be a hacker. After all, my friends all say that I hack code and my significant other says that 
I hack at our relationship! 

While I (and many other “old timers” in this game) strenuously resist the change that is 
taking place in the common usage of the term “hacker”, I also feel that it may be a bit of a lost 
cause to resist the change. This feeling is based on my observation that the media (like the trade 
press) has more power over the “common law” definitions in the language than we do (as the 
technicians that control our technical language.) 

Thanks, Criminals 

I will attempt to set the record straight in some future writings on the hacker matter, but 
for now I want to say a big “thanks” to to the computer criminals that have caused the recent 
stirs in the world’s data processing community with their break-ins from overseas. Yes, that is 
correct. As a practicing computer security consultant, I want to say thanks to the computer 
criminals! Fact is, I think that you ought to join me in thanking them. If you have not recovered 
from the shock of reading that last statements, please read on. 

Ater statements like that, I figure that you either believe that I have a legitimate point to 
make or believe that I am ready to give up my VAX/VMS and DECnet-VAX related computer 
security consulting practice! I assure you that I am not ready to give up my consulting practice, 
so let’s get started figuring out why we should thank computer criminals. 

Have you heard Retired Admiral Grace Hopper speak on the “state of the world of infor¬ 
mation processing?” If not, you are in for a shocker of a technical entertainment experience. Your 
DECUS Local User Group (LUG) can get a video tape of her address to the 25th anniversary 
celebration at the DECUS U.S. National Symposium in Dallas from the DECUS National LUG 
Organization video tape library. If your LUG has not seen the tape, have your LUG chairperson 
get a copy of it for the next LUG meeting. If you don’t know where your LUG is, find it by 
writing the national DECUS office at the address contained elsewhere in this newsletter. If you 
don’t have a LUG in your area, go start one! (I’ll even help you do it.) 
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In her talk, Admiral Hopper proposes that we (as the data processing industry) are woefully 
unaware of how important the data that we process is and show an amazing lack of interest in 
its well being and correctness as a result. She presents quite an articulate argument that we had 
better get ourselves oriented to not only the value and importance of the data that our machines 
process, but oriented to the potential for a first order societal disaster that could be induced by 
errors that are introduced into the data by our improper custodianship and/or processing as well. 
In addition she asserts that as a society, we only change as a result of large and self induced crises 
that do significant damage to us all. 

Given the nature of the data that our systems hold and process, you can probably accu¬ 
rately detail any sort of disaster that you can imagine. Failure to launch, an incorrect medical 
operation being performed, a sizable business bankruptcy and the ruin of someone’s credit life 
are but a few of the scenarios that you could come up with that could result from lax custo¬ 
dianship of data or out and out negligence. Simple examples of her theme can easily be found 
in the contemporary examples of commercial computer crimes that are well documented these 
days. Stories about dishonest and inept employees top the list. Remember the Equity Funding 
Scandal where the management of an insurance company inflated their stock’s value with scads 
of computer generated fraudulent insurance policies? Then there is the not-so-well documented 
case of the insurance executive that was retired with a gold watch after it was discovered that he 
had successfully embezzled $28 million from his employeer (you see, they didn’t prosecute since 
they didn’t want the bad PR!). 

With all of this as background, you’d think that the right thing do do with a computer 
criminal would be to shoot them on sight! After all, they are a menace to society and they have 
collectively cost everyone a lot of trouble. System down time, lost productivity, data corruption, 
monetary losses - and - lots of lost sleep and ulcers for us system and security managers! Why 
the nasty computer criminal creeps! After a system that I am responsible for has been attacked, 
I angrily shout “Hang the bastards!” 

Wait a moment. Is this a multiple personality here? I say that we ought to thank computer 
criminals and then I call them creepy bastards? What gives? 

As a final piece to the puzzle, you need to understand my argument is my experience as a 
technical trainer and a VAX/VMS consultant. By far the biggest problem that we find in the DEC 
based DP shops that we see and hear about is a severe lack of system and network management 
resources. Out of the things that we generally find missing, the most common is very simple - 
lack of time for the system and network managers to do their jobs. Of course, the jobs of system 
and network management includes system and network security management. Stated plainly, 
most system and network managers do not seem to have the time to do the security management 
portion of their jobs! Further, we typically find that the problem is really a manager that has 
not budgeted any time or resources for the system and network security job. Most system and 
network managers that we meet are sufficiently interested in this important aspect of their job 
to be doing the best that they can with it by begging, borrowing and stealing resources from 
other tasks that are “officially funded” to insure that their systems and networks are secure. The 
refrain “I’ll be a little late tonight, honey” wears thin after a time. 

There is one more piece to consider before you can see my justification in thanking the 
computer criminals. Currently, when a security related problem is discovered with either the 
operating system, the network, or layered applications software - it is not discussed in any way 
that system and network managers can expediently find out about them. Using the two security 
problems that have recently been fixed by DEC as examples, it is plain to see that both DEC and 
DECUS have been unable to come up with a way to discuss these sorts of problems in the sort of 
an open forum that would allow many of our systems from being compromised. While DEC built 
and shipped fixes to the problems as quickly as they could, all of our systems were wide open to 
attack during the time that it took them to do this. Worse, no one would talk about the problems 
so that we could at least monitor our systems more closely. The reasoning behind this behavior 
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that is being given is that if the problems are discussed openly, systems will be subjected to 
unnecessary exposure to “bad guys” that know about the problem. They say that there are many 
systems out there that are not even being protected at a minimal level and that to distribute 
information about the problem is needlessly arming criminals to do those systems harm. Just for 
the record, I say that these arguments are as flawed as those that the fundamentalist religious 
people use against sex education in grammer school. A typical fundamentalist argument against 
it is that sex education at a young age will “corrupt the morality” of our young people by inducing 
them to experiment with sex. I say that sex education is one of the only ways that we will ever 
put a cap on the AIDS epidemic! 

Now that you’ve read all of this, try the following on for size. 

Given: 

• That the safety and integrity of the data on our systems is at the very core of our infras¬ 
tructure, 

• The fact that we (as system and network security managers) generally have a hard time 
gathering the resources that we need to do the security part of our system and network 
management jobs 

• The fact that often security patches and information about security problems arrive to late 
to do us any good 

maybe it is appropriate for some force, “external” to our infrastructure, to “shake us up with a 
bit of reality therapy.” Come on now, when you last asked your manager for additional resources 
to do a better job of system or network management, what did they say? I’ll bet they sent you 
away feeling that it was your fault that system and network management even needs to be done 
(let alone not giving you the resources that you need to do the job!) 

Maybe we ought to thank computer criminals for reminding the custodians of the societies 
data that its safety and integrity are very important. Maybe we ought to thank the computer 
criminals for getting themselves on the front pages of newspapers across the country where man¬ 
agers and controllers of organizational resources can be told publically that they have problems 
that are not being properly addressed. Maybe we ought to thank computer criminals for remind¬ 
ing managers that our technology is not only fragile, but that it needs to be carefully managed as 
well. Maybe we ought to thank computer criminals for reminding DEC and DECUS that hiding 
from problems and management by ignorance is not appropriate - especially when our hardware, 
software and practices are so widely known and understood. 

Maybe we ought to thank computer criminals. What do you think? 

Let me hear from you on this! 

Until we meet again - Happy VAXing! 

Ray Kaplan, PIVOTAL, Inc., P.0. Box 32647, Tucson, Arizona 86751 
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Fellow educators: 

The dust should have settled on the spring DECUS in 

Cincinnati. I hope that you found many useful tools and 

thought provoking ideas. It is time to think about the 

Woods meeting in June and the fall DECUS. There is never 
any rest for the ones who are willing. 

If you are net familiar with a Woods meeting let me 
enlighten you. The Woods meeting is a time for the 

officers of the Sig , in this case EDUSIG, to get togather 

and plan out strategies for the up coming year. Many old 

questions will crop up as well as new ones. Costs, 
quality, presenters, new DEC products (both hardware and 
software) and the courtship with cur counter parts in DEC 
are among the many things discussed at these meetings. Now 

is the time to add your thoughts to the list. We need 

input. 

F.G.B. 

Taft College 
Taft, CA 93268 

The TESTGEN article discrib.es a software product that can be 
obtained from the Clearinghouse at Iowa State University. 
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TESTGEN 


TESTGEN# in one form or another# has a long history. Those 
of us at Taft College are grateful for the use of a prototype 
provided by Bakersfield College in 1981. This version of 
TESTGEN uas produced by Fred Bell of Taft College and Dan 
Esbensen# president of Touch Technologies# San Diego. TESTGEN 
is written using "Intouch"# a next generation language 
developed by Touch Technologies# Inc. A free run version of 
Intouch <TM> is included# courtesy of Touch Technologies. 

TESTGEN is a unique# easy to use# test generating program. 

It uses the "KISS“ principle to make it superior to other 
generating packages. TESTGEN can handle multiple-choice# 
true-false and matching type questions. It is completely 
menu driven u/ith on-line help for each menu. The main menu 
gives the user following choices: 

ADD - Add New Questions 
CHA - Change an Existing Question 
DEL - Delete an Existing Question 
LIS - List Existing Questions 
GEN - Generate a Test 

Entering questions or correct existing ones: 

The main menu will prompt the user for the type of task to 
perform# "ADD” for adding new question either to an existing 
chapter or a new one. If the user types "new" the menu 
prompts the user for the name of the chapter (max of 8 
characters)# with the usual rules for VMS file names. 

One of the unique features of TESTGEN is that it uses EDT as 
the editor for correcting or modifying test questions. Users 
do not have to learn to use another editor. Nhen typing the 
question TESTGEN uses prompts for the type of question 
(multiple-choice# true-flase or matching). Each question is 
terminated by a blank return. Backing up is another helpful 
feature. If an error was made in the previous responses for 
correction. Control-Z or “EXIT" will take the user from a 
sub menu to the main menu or exit the program altogether. 

Generating a test or getting a list of questions: 

The user is prompted for the test title# instructor's name# 
class type# letter or number choices# computer-selected or 
user-selected question in each test generating operation. 

The user has the folowing printing options: 

SCR - Print to Screen 

PRI - Print to Printer Port 

SYS Print to System Printer 

The option of printing from the printer port saves time and 
equipment. 


EDCJ-2 



Instructional strategies: 

The ease of use of TESTGEN makes it especially valuable for 
the comonly accepted practice of pretesting. It is not 
difficult to prepare two versions of an exam and allow 
students to practice the pretest from a terminal at their 
time and convenience. 

Such practice is consistent with the view that testing should 
measure learning and yet not become “game playing" barriers 
to student success. If used with a package such as Digital's 
Courseware Authoring System <CAS># then computer managed 
learning (CML) components come into playi allowing 
instructors to measure the time and effort that students are 
putting forth. 
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From the Editor: 

Hey folks! The Minitasker Folder is empty. There were only two articles for 
This newsletter is your medium for exchanging ideas, so send me some. 

Are there any of you out there who (like I) used Version 1 of RT-11? (Of 
course it wasn't called Version 1 at the time.) For our 15th anniversary. I'd 
like to collect your recollections of RT-11 over the years. Send your war 
stories, bugs, fixes, questions, comments, or ramblings to: 

John M. Crowell 
RT-11 Newsletter Editor 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 


Gary Sallee's Introduction to KERMIT/RT is long enough that I'm splitting 
it between this month's and next month's issues. (Mostly so I know I’ll have 
something to publish next month.) I found this article particularly useful. I 
think you will too. Bob Walravenn's FORTRAN SLATE addresses the problem 
of Virtual Arrays that get mapped into oblivion. It's all done with smoke and 
mirrors! 
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Kermit/RT/TSX Introduction 
Gary F. Sallee 

From Brian Nelson's KllART.DOC, KllF85.DOC, and KllINS.DOC 
Presented at the Regular SCURT LUG Meeting 
Southern California Users Of RT-11 
Pasadena, California 


ABSTRACT 

This is an introduction to Brian Nelson's KERMIT from the 
University of Toledo as it may be used in an RT-11 or TSX-plus 
computer system. Topics covered will be what Kermit does, how I 
use Kermit, what SYSGEN options are needed, how to set up the 
needed hardware, how to install Kermit, how Kermit talks to 
other Kermits, how to use KERMIT.INI, how to set up a dialing 
list, and anticipated futures by Toledo and by SCURT. 

USES 

Kermit is used to support file transfers to and from superminis 
such as the VAX and PDP-11 and remote personal computers, such 
as the PC, the Rainbow, and the Macintosh. Kermit is used as a 
basic terminal emulator. Kermit has a log file capability that 
can record data and/or commands from the terminal or the 
communication link. It is possible to control several RT-11 
systems from one "master" RT-11 multi-terminal system by wiring 
the "master" DL ports to the the "slave" console lines. Because 
there is an existing Kermit for almost any DEC configuration, 
then Kermit can be used as a poor man's Decnet. 

HOW I USE KERMIT 

I routinely use Kermit for transferring files between a TSX-plus 
system, RT-11 systems, RSTS/E systems, and VMS systems. I also 
use Kermit to control "slave" systems from a "master" TSX-plus 
system over DL serial lines. This provides a "super set host". 

I use Kermit's log file to record anomalies like crashes and ODT 
interactions on the "slave" systems. I use the Kermit log file 
to record data from a connected system or from dial up services 
such as DECUSERV and DECdirect: (800) 258-1710 (1200/2400 
baud). 

I have obtained the Toledo Kermit by dialing into the VAX 11/785 
at the University of Toledo: (419) 537-4411 (1200 baud. Service 
Class: VX785A, Account: KERMIT, Password: KERMIT). 

CONCLUSIONS 

Kermit-11 is useful, easy to run, and easy to install. 
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TERMINAL EMULATOR 

Terminal emulation can be done several ways: A Kermit program 
can provide a simple "glass tty" mode. A Kermit might provide 
an intelligent terminal emulation. In the case of a PC the 
emulation is likely to be of a VT100 series terminal. MacKermit 
provides this. Some mode of terminal emulation is generally 
required since the file transfer operation of Kermit requires 
that two Kermits to be running; one on the LOCAL system and one 
on the REMOTE system. The simplest method of running two 
Kermits at once is to use terminal emulator mode (CONNECT) on 
the local system as a terminal to log into the remote system. 
Then invoke the host's Kermit program. 

While logged onto the Host with the terminal emulator it is 
possible to use any of the host's services and programs. You 
are not limited to "RUN KERMIT", as far as the host allows you 
privileges. 

MY HARDWARE 

I have a DLV11-E modem port with the programmable baud rate 
enabled. The DLV11-E for a modem port is well supported in 
RT-11. I am using a DITTO 2400XL, a Hayes compatible modem 
which is made by Rockwell, Newport Beach (TR24-D310). I also 
have a SmarTEAM 103/212A Hayes compatible modem that I have used 
on the DLVll-E. 

I put my modem on CSR 176530 and Vector 330. This allows my 
first DLV11-J to have the console port and my second DLV11-J to 
start at an even CSR 176540 and vector 340. Be sure to set the 
jumpers for the desired CSR and vector on the serial card. 

OTHER HARDWARE 

The DZ/DZVl1 ports which support modem control can also be used. 
The DH/DHVl1 port may be used but Kermit does not support the 
SET SPEED command yet. A plain vanilla DL port can be used to 
dial out if you do not want to change the transmission speed 
from the operating system. The SET SPEED command is not 
supported for RT-11; it is supported for TSX-plus. So for a 
dial out line with RT-11 Kermit-11 V3.56, there is no 
disadvantage to using a vanilla DL line. 

HOW I SET UP MY HAYES COMPATIBLE MODEM 

DTR forced on (Not good for RSTS/E or RSX, but ok for RT-11) 
Hayes word result codes 
Send Hayes result codes 

No echo in command mode (Important with TSX+. RT-11 echo is ok.) 
Auto answer enabled ( Probably no reason for this for RT-11) 

Set CCITT V.22 bisync mode ( This is for 2400 baud) 

Set default speed 2400 baud 


Hayes commands are enabled. 

RTS is disconnected 
RLSD/CD to DSR loop is off 
Asynchronous line communication mode 
Internal Sync Clock 

The Cable from the DLVll-E to the Modem RS232-C includes null 
modem 


RS232-C 

: DB25 


DLVll-E 50-PIN BURG 

EIA PIN NAME 

NAME 

PIN 

NAME 

AA 

1- 

P-GND 

— *protective ground 

A 

protective ground 

AA 

1- 

P-GND 

— *protective ground 

VV 

protective ground 

BA 

2- 

TD < 

— *transmit data 

F 

transmit data 

BB 

3- 

RD 

—>*receive data 

J 

receive data 

CB 

5- 

CTS 

—>*clear to send 

T 

clear to send 

AB 

7- 

S-GND 

— ^signal ground 

B 

signal ground 

AB 

7- 

S-GND 

— *signal ground 

UU 

signal ground 

CF 

8- 

RLSD 

—>*carrier detect (CD) 

BB 

rev. line signal 
detect 

CD 

20- 

DTR < 

— *data terminal ready 

DD 

data terminal ready 

CE 

22- 

RI 

—>*ring detect 

X 

ring indicator 




★ 

M 

EIA interlock 




★ 

E 

EIA interlock 

CA 

4- 

RTS < 

request to send 

none 

(V) 

CC 

6- 

DSR 

—> data set ready 

none 


SBA 

14- 

STD < 

2nd transmit data 

none 

(FF) 

SBB 

16- 

RD 

—> 2nd receive data 

none 

( JJ) 


17- 

RxCLK 

—> receiver clock 

none 



23- 

SPDS < 

speed select 

none 



24- 

TxCLK< 

transmitter clock 

none 



25- 

FB < 

— force busy 

none 

(C) 


Note: * is a real wire. Signal ground is connected to 

protective ground. 6-DSR from modem is not connected. 4-RTS to 
modem is not connected. 

FORCING DTR 

Forcing the assertion the DTR signal to the modem is normally 
not recommended if full function auto answer from the operating 
system is desired. But DTR control and auto answer are normally 
not used with RT-11; and TSX-plus does not treat the DTR signal 
in a manner compatible with non-DEC modems. So forcing DTR 
becomes a necessity in most RT-11 or TSX-plus environments. The 
cost of forcing DTR is in ieduced utility: the HANGUP and the 
BYE commands will not hang up the remote line. 

Some people will go to great lengths to make their TSX-plus 
system work without forcing DTR. Greg Adams has a "fix-it" 
program that wakes up every minute. It resets DTR, then sets 
DTR, for any inactive modem dial in line. This program for the 
DTR compatibility problem will allow the BYE command to work as 
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a log off and hang up operation. Greg claims that this is what 
VMS does with it's modem lines. 

RT-11 OPERATING SYSTEM SET UP 

RT-11 Sysgen options must include 1) timer support and 2) 
multi-terminal support or the XL handler (XC for pro). Do not 
use multi-terminal support faster than 1200 baud. 

Multi-Terminal support is not required if the XL handler is 
used. FB or XM is desired because timer support is in the 
distributed systems, but SJ with sysgened timer support is ok. 

Kermit-11 supports the XL and XC handlers, supports the multiple 
terminal service, and supports the use of the console line for 
connecting to the RT-11 system. 

The best modem handler for RT-11 is the XL driver (XC on pro), 
available on RT-11 version 5.1 and later. This driver makes 
very efficient use of a DLll or DLVll interface. It's the same 
handler that is used by VTCOM. To use XL, you must have an 
extra DLll/DLVll interface port in addition to the console 
interface. 

The XL handler supports two DCL commands: 

SET XL CSR=n,VECTOR=m 

Where: "n" is the control status register address and "m" is 

the interrupt vector address. 

The first default sysgen DL address is 176500 for the CSR, and 
300 for the interrupt vector. Be sure to set the handler's CSR 
and the vector according to your hardware straps on the serial 
module. 

The XC handler, used ONLY on the PRO/300 series, has it's CSR 
and vector fixed at 173300 and 210 respectively. Kermit-11, 
upon finding itself running on a PRO/3xx under RT-11, does an 
implicit SET LINE XC. The DCL command SET XC SPEED~N must be 
used outside of Kermit to change the XC line speed from the 
default of 1200 baud. 

The Multiple Terminal (MT) support requires a SYSGEN. Serial 
lines in the MT case are designated by numbers; the console is 
always line zero. The next line, say a DLVllE, is line one. 
These line numbers are assigned during SYSGEN based upon the 
order of entry during SYSGEN (under RT V5.2, the questions start 
with question number 180). You can also use a DZ11 or DZVll. 

The actual assignments may be viewed on a running system with 
the DCL command SHOW TERMINAL (SHO TER). 

If there is no way to get an additional interface into your 
system (perhaps you have a four slot QBUS back plane), then you 


can force Kermit to use the console. This implies, of course, 
that it will not be possible to dial out from the RT-11 system; 
the system could be used only for a remote Kermit to connect to 
it via the console port. If Kermit finds that the XL handler is 
not present, and that multiple terminal service is absent, it 
will force the use of the console. 

To force the console to be used, command: 

Kermi t-ll>SET LINE TT: 

In summary, the following commands specify serial lines for 
RT-11: 

Kermit-ll>SET LINE 1 use terminal line one 

Kermit-ll>SET LINE XL use the XL handler 

Kermit-ll>SET LINE TT: force use of the console line 

Kermit-11 also requires the presence of timer support in the 
executive. This is required to support the .TWAIT directive; FB 
and XM systems always have support for this; SJ systems by 
default do not. If Kermit decides that it does not have a 
clock, which it would think if .TWAIT support is missing, it 
will try to fake .TWAIT's with cpu bound loops. The best thing 
is to insure that you have a FB or XM monitor available for use 
with Kermit. 

KERMIT.INI FOR RT-11 

The file KERMIT.INI must be on SY: 

1*TITLE* - KERMIT.INI - Customize Kermit for RT-11 

SET MODEM HAYES 

SET CONSOLE 8 

SET PROMPT K-l1 LOW BALL> 

SET LOGFILE KllLOG.TXT 
SET PHONE TONE 

SET PHONE NUMBER DECDEMO 1,800,3323366 

SET PHONE NUMBER DCS 1,800,2477003 

SET PHONE NUMBER DECUSE 1,617,485,2574 

SET PHONE NUMBER WORK 5551212 

SET LINE XL 

DIAL WORK 

CONNECT 

TSX—PLUS OPERATING SYSTEM SET UP 

The TSX-plus SYSGEN options that must be included are 1) 100. 
blocks of PLAS swap file (SEGBLK) and 2) one spare CL unit or 
the XL driver. The CL may be dedicated (for dial out only), or 
may be spare (the time share line can be used for dial in, too). 
The PLAS swap file is not needed if the K11RT4.SAV image is used 
for KERMIT.SAV. 
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Kermit-11 can be used on TSX-plus (a product of S&H Computing) 
as either a LOCAL and a REMOTE. A LOCAL Kermit (you connect out 
to another system using the CL handler) is similar to Kermit use 
on RT-11 with the XL/XC handler. A REMOTE TSX-plus Kermit (you 
log into a TSX-plus system and run Kermit-11 on the REMOTE) is 
identical to Kermit use on most multiuser systems (for example, 
TOPS-20 and RSTS/E). 

In order to CONNECT out from TSX Kermit to another system, you 
need to associate the appropriate DL line with a CL or an XL. 
This association can be at SYSGEN time or with an ASSIGN. See 
the examples below: 

Kermit-11>SET LINE CL2 

or: 

.SET CL2 LINE=4,NOLFOUT 

.ASS CL2 XL 

.KERMIT 

Kermit—11>SET LINE XL . 

The image KllXM.SAV will use approximately 100 blocks of PLAS 
swap file space. If Kermit fails to load, then the TSGEN.MAC 
parameter SEGBLK may be too small to contain KllXM's virtual 
overlay; the TSX-plus system manager will need to increase 
SEGBLK and reboot TSX-plus. If adding 100 PLAS blocks is 
excessive, then the disk overlayed image K11RT4.SAV may be used 
for KERMIT.SAV. 

In TSX-plus, I find no degradation in using K11RT4.SAV. The 
generalized data cache is probably of assistance on a busy 
system. 

Note that if you have 256 Kbytes or less of memory on your 

TSX-plus system, then Kermit can be a system hog. If you have 

256 Kbytes or less, please don't do anything else while Kermit 

is running (i.e. B to print screen or Wn to window). If you 

do, then the system will probably slow to a snail under tortoise 
pace. 

Without the added concurrent task on a 256 Kbyte system, Kermit 
is good and fast. But with the low cost of memory now, please 
put in another 256 Kbytes or more. You will like it. 

KERMIT.INI FOR TSX-PLUS 

The file KERMIT.INI must be on SY: 

!*TITLE* - KERMIT.INI - Customize Kermit for TSX+ 

SET MODEM HAYES 

SET CONSOLE 8 

SET PROMPT K-ll HIJACK> 

SET LOGFILE KllLOG.TXT 
SET PHONE TONE 
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Kermit will fetch the handler if it is not resident. 

CONNECTING THE SYSTEMS 

The first thing to do, before starting Kermit, is to get the 
modem turned on and set up. I have a separate power switch on 
my modem. The modem is only on when I anticipate a need. I 
modify some of the modem's set up parameters. This modification 
is not necessary and for initial check of a set up nor for many 
applications. 

The command files that I use for the modem set up are below: 

!*TITLE* - LOADMM.COM - Load Modem parameters 
SET CL2 LINE=3,SPEED=1200,NOLFOUT,DTR 
COPY SY:LOADMM.000 CL2: 

COPY SY:LOADMM.010 CL2: i 5 SET CL2 LINE=0 
The LOADMM.000 file is Hayes attention: 

AT 

The file LOADMM.010 sets some Hayes modem parameters: 

AT T S0 = 2 S6 = 4 S7 = 95 S10=13 Sll=100 Xl 
Hayes parameters explained: 

T 1 TONE DIAL: DEFAULT IS PULSE DIAL 

S0 = 2 l 2 RINGS BEFORE ANSWER: DEFAULT IS ANSWER FIRST 

RING 

56 = 4 1 WAIT FOR DIAL TONE 4 SECONDS: DEFAULT IS 2 SECONDS 

57 = 95 i WAIT FOR REMOTE CARRIER 95 SECONDS: DEFAULT IS 30 

SEC. 

Si0=13 I CARRIER LOSS TIME 1300 MS.: DEFAULT IS 700 MS. 
Sll=100 ! TONE DIAL SPEED 100 MS: DEFAULT IS 70 MS. 

Xl I EXTENDED RESPONSE SET: DEFAULT IS X0: BASIC SET 

If we wish to dial out, then the DIAL command is issued. 

The ''number’' for the DIAL can be a predefined symbol from the 
SET PHONE NUMBER command, or can be an input number typed in. 

When the two modems agree on a speed and protocol, then Kermit 
will issue the message: 

Connection made, type CONNECT to access remote 

The normal next thing to do is to type CONNECT<RETURN> to start 
the remote system logon operation. But now is the time to enter 
any other command that needs to be issued, like SET SPEED 300, 
before the CONNECT. Also, if the remote system is a PC or an 
RT-11 with the console as the communication port, then the 
remote will already be running Kermit, so the CONNECT is 
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inappropriate. 

When we are connecting two physically close systems without a 
modem, we would simply connect DL ports together with a NULL 
modem cable and then invoke Kermit on each system. 

If the REMOTE is a single user system (i.e. RT-11 or a PC), 

then the single user system would most often be set up as a 
Kermit "server". This allows the LOCAL system to control the 
server and to initiate file transfer requests without the need 
for the operator to move between the two machines. 

STARTING KERMIT 

Once the physical link has been made, we would log into the 
remote system, then invoke Kermit on that system and run it as a 
server. This is done by typing SERVER on the remote Kermit. 

Then escape back to the LOCAL Kermit with the <CTRL>C. 

RUDIMENTARY KERMIT COMMANDS 

Now that we have established the physical link, how do we get 
files transferred? Quite simple. First we give the remote 
Kermit the SERVER command, then we continue as below: 

REMOTE Kermit-11>SERVER Request the remote 

Kermit to SERVE 

< CTRL> C 

LOCAL Kermit-ll>GET [file.type] Request a file from the 

remote system 

LOCAL Kermit-ll>SEND [file.type] Send a file to the 

remote system 

LOCAL Kermit-ll>FINISH Request the remote exit 

Kermit 

LOCAL Kermit-ll>CONNECT Connect to the remote 

system. 

.LOGOFF 

<CTRL>C 

LOCAL Kermit-ll>EXIT Exit kermit 


The BYE command does not work for REMOTE TSX-plus or for REMOTE 
RT-11. 

These are the commands we need when talking to a Kermit server. 
There are, of course, many other commands which support file 
manipulation on the host, as well as obtaining REMOTE HELP. 
These commands are normally thought of as REMOTE commands. 
Indeed, they are prefixed by the REMOTE keyword, as in: 

Kermit-11>REMOTE HELP 

Kermit-ll>REMOTE COPY FILEl.TYP FILE2.TYP 
Kermit-ll>REMOTE CWD [USERFILES] 
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SET PHONE NUMBER DECDEMO 1,800,3323366 
SET PHONE NUMBER DCS 1,800,2477003 
SET PHONE NUMBER DECUSE 1,617,485,2574 
•SET LINE CL2 


Note that the SET LINE CL2 command is commented out with the 


"l". This is only because Kermit is sometimes used for dial in. 
If the SET LINE CL2 is attempted from a dial in line, then there 
will be an assignment conflict. I leave the comment line in the 
KERMIT.INI file to remind me which line I am supposed to set 
when I am dialing out. If kermit is only used for dialing out, 
then it is ok to activate the SET LINE CL2 command in the 


KERMIT.INI file. 


INSTALLING KERMIT ON RT-11 AND TSX-PLUS 


KERMIT.SAV is required, all other files are optional. 

The RX02 floppies distributed at the SCURT meeting contain the 
files: 


K11XM.SAV Copy to SY:KERMIT.SAV for RT-11 XM, PRO/RT-11 and 
TSX-plus 

K11RT4.SAV Copy to SY:KERMIT.SAV for RT-11 SJ and FB, usable 
on TSX-plus 

KllHLP.HLP Copy to SY: or DK: for online help file. This is 
optional. 

KllUSR.DOC Print file of the Kermit-11 user's guide 

KERMIT.INI is created on SY:. This is optional. 

Note that on the PRO/350 RT-11 you may have to UNLOAD XC before 
Kermit-11 can be started via a .FRUN command. Additionally, 
when running in the foreground, you will likely want to give the 
command: 


.FRUN KllXM.SAV 


~F 

Kermit-11>SET QUIET 


In the event that you are using RT-11 with multiple terminal 
support, you could use a command of the form: 

.SHO TER 


Unit 

Owner 

Type 

Width 

Tab 

CRLF 

FORM 

SCOPE 

SPEED 

0 

S-Console 

DL 

132 

No 

Yes 

No 

No 

N/A 

1 

Remote 

DL 

80 

Yes 

Yes 

No 

No 

N/A 


.KERMIT 

Kermit-11 T3.44 Last Edit: 04-Feb-86 
Kermit-11>SET LINE 1 


If you are you are using the XL handler (XC for the PRO), then 
the XL handler must be installed; it does not have to be loaded. 
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Kermit-ll has the following commands available: 


@ 

BYE 

CONNECT 

COPY 

CWD 

DELETE 

DIAL 

DIRECT 

DISCONNECT 

DISPLAY 

ERASE 

EXIT 

FINISH 

GET 

HANGUP 

HOST 

LOCAL 

LOGFILE 

QUIT 

PRINT 

RECEIVE 

REDIAL 

REMOTE 

RENAME 

SEND 

SERVER 

SET 

SHOW 

TAKE 

TRANSFER 

TYPE 

WHO 


Synonym for TAKE 
Log out a remote server 
Connect to a remote system 
Local copy of a file(s) 

Set new working directory 
Local delete of a file(s) 

Have a connected modem dial a number 

Local directory display 

Hang up a remote line 

Internal debugging 

Local delete of a file(s) 

Exit to system 

Stop a remote server without logging out 
Get a file(s) from a remote server 
Hang up a remote line 

Execute system command locally (where 
applicable) 

Force interpretation of command to the local 
system 

Create a log file 
Same as EXIT 

Print a file locally (where applicable) 
Receive a file(s) from a remote kermit 
Have a connected modem redial a number 
several times 

Prefix for file management commands to a 
server 

Local rename of filename(s) 

Send a file(s) to a remote Kermit 

start a Kermit server 

Change Kermit parameters 

Display Kermit parameters 

Execute indirect command file 

Send an ASCII file without Kermit protocol 

Local display of file on terminal 

Local display of logged in users (RSTS/E 

only) 


Commands for File Transfer 

SEND, TRANSFER, Abort control characters 
RECEIVE, GET 


Server operation 

SERVER, BYE, FINISH 
REMOTE 

REMOTE COPY, REMOTE CWD, REMOTE DELETE 
REMOTE DIRECTORY, REMOTE HELP, REMOTE HOST 
REMOTE LOGIN, REMOTE RENAME, REMOTE SPACE 
REMOTE TYPE, REMOTE WHO 

Commands for Local File Management 


The Connect Command 
CONNECT 

The Set Command 

SET ATTRIBUTES, SET BAUD, SET BINARY-TYPE, 

SET BLOCK-CHECK, SET CONSOLE, SET DEBUG 

SET DELAY, SET DEFAULT 

SET DIAL, SET MODEM USERDEFINED 

SET DTR, SET DUPLEX 

SET END-OF-LINE, SET ESCAPE, SET FILE 

SET HOME, SET IBM-MODE, SET LINE 

SET LOGFILE, SET MODEM, SET PACKET-LENGTH 

SET PARITY, SET PAUSE, SET PHONE, SET POS 

SET PROMPT, SET RECEIVE 

SET RECORD-FORMAT, SET RETRY 

SET RSX, SET RT-11 

SET SEND, SET SPEED 

SET TIMEOUT, SET TERMINAL, SET UPDATE 

The Dial Command 
DIAL 
REDIAL 


Before continuing, please note that Kermit programs do not 
necessarily implement the same level of support. In general, 
the large system Kermits, such as Kermit-32 (VMS), Kermit-20 
(Tops-20) and Kermit-ll (PDP-11 and PRO) support a large command 
set. No single command is really required by Kermit; the 
protocol specifies the transportation of files, not the command 
interface. At a minimum, however, a Kermit program requires the 
SEND and RECEIVE commands to effect file transfer. SERVER 
support is optional. If we don't have server support available 
then we must use the SEND and RECEIVE commands and tell each 
Kermit such for every time we want to move a file. 




Editor's note: 

Part 2 of this article will appear next month. 
It will include descriptions of the KERMIT 
Protocol and how KERMIT transfers files. 
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The FORTRAN Slate 

Bob Valraven 
Multivare, Inc. 


Last time I said I would say more about running FORTRAN-77 
programs as RT-11 system jobs, but an interesting F77 SPR came in 
that I wanted to tell you about, so we'll continue the discussion 
about system jobs next time. 

The SPR reported a problem accessing virtual arrays both from a 
program's mainline code and from a completion routine: after the 
completion routine is called and control is returned to the 
mainline code, the pointers to the virtual arrays may be 
incorrect. The FORTRAN-77 documentation doesn't explicitly say 
you can't access virtual arrays from both the mainline and a 
completion routine, but a little thought will tell you that it 
can lead to problems. 

The FORTRAN-77 (and FORTRAN-IV) virtual array support is based on 
the assumption that a single thread of code will be accessing the 
extended memory area where the virtual arrays are stored. For 
example, you would not expect virtual array support to work 
correctly if both a foreground and a background program were 
independently reading the same area of extended memory because 
each program would change the the mapping into the extended 
memory without informing the other program. 

Although RT-11 completion routines are built into a program so 
that they can pass data back and forth with the mainline code, 
they are run almost as if they were an independent program. That 
is, when RT-11 decides to run a completion routine, it interrupts 
the mainline code at wherever it happens to be and saves the 
register context before calling the completion routine. On 
return from the completion routine, the register context for the 
mainline code is restored and the mainline is started up where it 
left off. 

I was talking to one of the RT-11 engineers recently and 
mentioned this SPR. He said that they had talked about the 
possibility a while back of changing RT-11 so that when a 
completion routine is run the mapping register contents are also 
saved, but they have not made that change so far. The important 
point is that RT-11 DOES NOT SAVE THE MAPPING REGISTER CONTEXT 
WHEN A COMPLETION ROUTINE IS CALLED. The implication of this is 


that unless the user explicitly saves and restores the mapping 
register context on completion routine entry and exit, virtual 
array mapping may. be corrupted on return to the mainline code. 

The mainline code can also change the mapping the completion 
routine thought was in effect, so on the second call to the 
completion routine its virtual array mapping may also be 
corrupted. 

The bad news is that you can't blithly reference virtual arrays 
in the mainline code and a completion routine, but the good news 
is that there is very little you have to add to the completion 
routine to make it work. The following MACRO module describes 
how to modify your completion routine and supplies two 
FORTRAN-callable routines you need to use. The MACRO module is 
followed by a sample FORTRAN-77 program to demonstrate the use of 
virtual arrays in the mainline and a completion routine. 

.title VIRMAP 


This module contains two FORTRAN-77-callable subroutines that make it 
possible to reference a virtual array element in an RT-11 completion 
routine. 

DISCUSSION: 

For a FORTRAN-77 program that has virtual arrays, PAR7 is used as 
a window into the extended memory address space where the virtual 
arrays reside. Whenever a FORTRAN-77 virtual array element is 
referenced in a program, the F770TS virtual array support routines 
check to see if the element is in the window that is currently 
mapped into PAR7. If it is not in the window, PAR7 is remapped 
to a window that contains the element. 

RT-11 FORTRAN completion routines can be scheduled from several 
SYSLIB programmed requests. Completion routines can interrupt 
the mainline code at any point. RT-11 calls FORTRAN completion 
routines as co-routines so that all registers can be saved before 
the completion routine is called and the registers automatically 
restored when the completion routine returns. This is done to 
preserve the register context of the mainline code and to allow 
any FORTRAN subroutine to be used as a completion routine. 

If a FORTRAN-77 virtual array element is referenced in an RT-11 
completion routine and remapping is performed, then the mapping that 
was in effect when the completion routine was entered is no longer 
valid. If the original mapping is not restored when the completion 
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routine finishes, then subsequent virtual array references in the 
mainline code may corrupt data in the virtual array that the 
completion routine last referenced. This problem can be corrected 
by saving the FORTRAN virtual array mapping context at the start 
of the completion routine and restoring it when the completion 
routine is done. The two FORTRAN-77-callable subroutines GETMAP 
and PUTMAP in this module provide this capability. 

Likewise, if the virtual array mapping is changed in the mainline 
code between calls to the completion routine, the completion 
routine doesn't know this has occured, so it may corrupt whatever 
virtual array data the mainline was accessing at the time the 
completion routine was run. This problem can be corrected by 
forcing the completion routine to ALWAYS remap on entry. 

Note that these problems are not caused by a bug in FORTRAN-77, but 
result because of the way an RT-11 completion routine can 
asynchronously interrupt the mainline code. FORTRAN-77 has no 
way of knowing that a particular subroutine is going to be used 
as a completion routine, so it can't take any corrective action. 

The virtual array mapping data consists of a 7-word Window 
Definition Block (WDB) plus the current low and high window 
addresses. This data is contained in the OTS impure area. The 
routine GETMAP saves the mapping data in a user-supplied array, 
and the routine PUTMAP restores the mapping data and remaps PAR7 
to the original window as indicated by the WDB. 


USAGE: 


The following FORTRAN-77 completion routine demonstrates how 
GETMAP and PUTMAP are to be used: 


C 

C 

c 

c 

c 


subroutine INIT ( VARRAY ) 


This subroutine must be called once in the mainline code 
so that virtual array address information for VARRAY can 
be picked up for the completion routine entry point COMPLT. 
The mainline code must declare VARRAY to be a virtual 
array. 


virtual VARRAY(0:100) 

virtual IDUMMY(l) 

integer*2 mapdat(9) 
return 


! A virtual array defined in the 
! mainline code that is to be 
! referenced by completion routine 
! A dummy virtual array to force 
! correct completion routine mapping 
! Mainline mapping data stored here 


C- This entry point is the actual completion routine: 

entry COMPLT(id) 

C- Save the mainline virtual array mapping information 

call GET MAP ( mapdat ) 

C- Reference the dummy virtual array to force the code below 

C- to remap on the first reference to the virtual array VARRAY. 

C - This must be done because this routine does not know that 

C - the mainline code may change virtual array mapping between 

C- calls to this routine. 


i = IDUMMY(l) 

(Reference the virtual array VARRAY here as needed) 

C- Restore the mainline virtual array mapping information 

call PUT MAP ( mapdat ) 
end 


.mcall .WDBDF .MAP .PRINT .EXIT 
.WDBDF 

; Offsets to OTS impure area current low and high window addresses 

w.wnlo = 260 
w.wnhi = 262 

; Error Message 

.psect MAP$D,d 

MSG: .asciz /?PUTMAP-F-window mapping error/ 

. even 


RT-15 


RT-16 



















; The FORTRAN-77-callable routines: 


.psect MAP$I,i 
GETMAP:: 

mov 2(r5),r2 

mov #wndow$,rl 

mov #7,r0 

10$: mov (rl)+,(r2)+ 

sob r0,10$ 

20$: mov #$0TSVA,r3 

mov w.wnlo(r3),(r2)+ 

mov w.wnhi(r3),(r2)+ 

return 

PUTMAP:: 

mov 2(r5),r2 

mov #wndow$,rl 

mov #7,r0 

20$: mov (r2)+,(rl)+ 

sob r0,20$ 

.MAP #VNMAP$,#VND0V$ 

bcc 30$ 

.PRINT #MSG 
return 

30$: mov #$0TSVA,r3 

mov (r2)+,w.wnlo(r3) 

mov (r2)+,w.wnhi(r3) 

return 

. end 


r2 -> mapdat 

rl -> 0TS impure area VDB 
rO = length of a VDB 

; Move VDB to mapdat 


; r3 -> start of 0TS impure area 
; Save low window address in mapdat 
; Save high window address in mapdat 


; r2 -> mapdat 
; rl -> OTS impure area VDB 
; rO = length of a VDB 

; Move mapdat to VDB 


; Remap to the original window 
; Branch if no error 
; Otherwise throw up on user's 
; console 

; r3 -> start of OTS impure area 
; Restore low window address 
; Restore high window address 
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*************************************************************************** 
program SPR081 


This program demonstrates by example how to access virtual arrays from a 
completion routine. It uses the FORTRAN-77-callable MACRO routines GETMAP 
and PUTMAP in the module VIRMAP.MAC to save and restore the mainline code 
mapping. 

Build the program as follows: i 

.fortran spr081 
.macro virmap 

.link spr081,virmap,sy:virtxm/xm 


virtual fill(30000) ! array continuously filled in mainline 

virtual iget(0:4095) ! array sampled by completion routine 

type *, 'SPR081 demonstration:' 
type *, ' ' 

type *, 'This program uses the RT-11 request ITIMER to schedule a' 
type *, 'completion routine that types out the first 20 elements' 
type *, 'of a virtual array. The completion reschedules itself' 
type *, 'to run at one second intervals. The data displayed by' 
type *, 'the completion routine should be the numbers 0 through 19,' 
type *, 'consecutive. If any other data is printed, the virtual' 
type *, 'array referenced by the completion routine was corrupted' 
type *, 'by the mainline program. Vhen the completion routine is' 
type *, 'not running, the mainline fills a different virtual array' 
type *, 'and verifies it has not been corrupted by the completion' 
type *, 'routine. If it has, the program will stop with error.' 
type *, ' ' 

type *, 'If this program is running correctly, it will run' 
type *, 'continuously until you type a double ctrl-C.' 
type *, ' ' 

type *, 'Press RETURN to start demonstration:' 
accept '(Al)' , i 

! ITIMER requires one extra queue element 
i = IQSET (1) 


RT-18 








! Initialize the array to be sampled by completion routine 


do 10 i=0,4095 
iget(i) = i 
10 continue 

! Pass virtual array address information to the completion routine 
call INIT (iget) 

! Start the timer 
call TIMER1 

! Loop here filling and verifying the local virtual array forever 

20 continue 

do 30 i=l,10000 
fill(i) = i 
30 continue 

do 40 i=l,10000 

if ( fill(i) .ne. float(i) ) then 

type *, '?SPRXXX-F-fill error at i = ',i 

stop 'Use of virtual arrays in completion routine incorrect' 
end if 
40 continue 

go to 20 

end 


subroutine TIMER1 

! TIHERl schedules completion routine PLAYBK to be run after 1 second. 

integer*2 area(4) 
external PLAYBK 

call ITIMER ( 0 , 0 , 1 , 0 , area , 1 , PLAYBK ) 
end 


subroutine INIT ( IGET ) 

! INIT must be called once in the mainline code so that virtual array 
! address information for IGET can be picked up for the completion 
! routine entry point PLAYBK. The mainline code must declare IGET 
! to be a virtual array 

virtual IGET(0:4095) ! Array to be sampled by completion routine 

virtual IDUMMY(l) ! A dummy virtual array used to force the 

! completion routine to map correctly 
integer*2 mapdat(9) ! Mainline mapping data stored here 
return 

! . 

! This is the entry point for the timer completion request: 

entry PLAYBK(id) 

! Schedule another timeout interval 

call TIMER1 

! Save the mainline virtual array mapping information 
call GET MAP ( mapdat ) 

! Reference the dummy virtual array to force the code below to remap on 
! the first reference to the virtual array IGET. This must be done 
! because this routine does not know that the mainline maps away the 
! virtual array IGET between calls. 

i = IDUMMY(1) 

! Print the first 20 elements of the virtual array IGET to verify that 
! they are correct. 

write (5,'(lx,1017/lx,1017/)') (IGET(j),j=0,19) 

! Restore the mainline virtual array mapping information 
call PUT MAP ( mapdat ) 
end 

**************************************************************************** 
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DECUS PROGRAM LIBRARY 


Corrections to programs that have been announced through this 
report 

DECUS No. VAX-288, Title: REPORT WRITER, add “Submit¬ 
ted by: W29-50, Los Angeles .CA". 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

VAX/VMS FAMILY OF COMPUTERS 

DECUS No: V-SP-74 Title: Symposium Collection from the OA 
SIG. Fall 1987, Anaheim Version: March 1988 
Author Various 

Operating System: VAXA’MS Source Language: ALL-IN-1 
Keywords: ALL-IN-1. Symposia Tapes - VMS 

Abstract* This submission contains the programs submitted to 
the OA SIG at the Fall 1987. DECUS U S .Symposium in Anaheim, 
California.lt includes the following subdirectories and topics 
located in directory [.OA88AJ. (For more specific and detailed 
information, please refer to the AAAREADMETXT in each 
directory/subdirectory). The following is a brief summary of the 
contents of the office automation collection . 

I. 

[.BRUNER] 

[.ANSWER_FILE_] 

OR_DELETE] 


[.A_ONE_HELPS] 


[.INTERFACE] 


[MULTIPLE_ATTACH] 


[.NEXT_OR_PRE¬ 

VIOUS] 


[.QUEUE_MANAGE¬ 

MENT] 


[.SYS_DICT] 


[.SYS_UDP] 


An ALL-IN-1 script to enable the 
user to dispose of the originalmail 
message as part of the Answer pro - 
cedure. 

Contains articles “3 HELPS” and 
‘YOURS,MINE, & OURS ”and re¬ 
lated forms, scripts, and command 
procedures. 

An ALL-IN-1 application for con¬ 
trolling access to ALL-IN -lfunctions, 
DCL commands, and external ap¬ 
plications. 

An ALL-IN-1 function to allow the 
contents of a selection list to be 
attached automatically to the cur¬ 
rent mail message (replaces pre¬ 
vious MAIL FOLDER function). 
Two ALL IN-1 functions for locat¬ 
ing the next or the previous docu¬ 
ment in numeric sequence from the 
current document. 

Four ALL-IN-1 functions which 
allow the users to specify a form 
name for printing, reset the queue, 
show queue .and delete a job from 
the queue. 

An ALL-IN-1 facility for creating 
and using site-specific System Dic- 
tion-aries. 

An ALL-IN-1 facility for accessing 
User or System UDP's. 


II. 

[.COY] 

[COLORS] 

[.DM$SD] 

[.MAKE_TLB] 

[MCL] 
[SHOWME ] 

f.VAXNOTES] 

[.WPE] 


[.WPELSE] 


III 

[.GILBERT] 

[.EMP] 


[.LN03] 


[.SWP] 


A package for managing and set¬ 
ting ‘default” colors forVT241and 
VT340 terminals. 

An extensive revision of the H avre/ 
Gregory Directory Management 
package. A revision of Alan L. 
Zirkle s SET DEFAULT program. 
Procedures for making a DXC Com¬ 
pressed Text Library from all “text ” 
files in a directory. 

Two programs for producing multi - 
column listings. 

Program which provides users with 
node, terminal, and process infor¬ 
mation. 

Some useful things for systems run - 
ning VAXNOTES. 

A “complete” and extended imple¬ 
mentation of WPS-PLUS for edit¬ 
ing ASCII files, including some 
language sensitive features for 
.COM files. 

An implementation of WPS-PLUS 
for LSE. 


A hierachical Employee Data phone 
directory and database, which re¬ 
places “ALL” and ‘COR” phone 
directories under ALL-IN-1. 

A modification to the LN03.PRA 
file which enables printing 66 lines 
per inch in portrait orientation, fixes 
total line count error when using 
eight lines per inch, and will count 
lines correctly when using “GOLD 
PAGE” (if down-line load fonts are 
available). 

A Shared Word Processing System 
under ALL-IN-1. 


IV. 

[.IOELE] 

[.A1CALCHK] 


An ALL-IN-1 function to allow a 
user to determine for a given day 
when one or more users have ac¬ 
tivities on their own calendars. 


V. 

[.LEDERMAN] 

[.ACCOUNTING] Programs to convert System Ac¬ 

counting and PSI Accounting data 
to a normalized form readable by 
DATATRIEVE and other languages 
with record definitions. 

[.ALL-IN-1] Contains DTR definitions to work 

ALL-IN-1 logging and data files: 
document database also works with 
WPS- PLUS/VM S. 


[.CORPHONE] 

DTR replacement for ALL-IN-1 
corporate phone directory. 

[.FUNCTIONS] 

User defined functions: DTR pro¬ 
cedures for cataloging, defining, and 
generating functions. 

[.NEWSLETTERS] 

Past issues of the “Wombat Ex¬ 
aminer” newsletter. 

[.PLOTS] 

Additional PLOTS and articles on 
adding your own plots. 

[.RECALL] 

Uses SMG to provide command line 
recall in DTR; plus DAB definitions 
in “C”. MACRO-32. 

[.RSX_ACCOUN 

Process RSX-11M-PLUS system ac¬ 

TING] 

counting and RSX console logs 
with DTR. 

[.SESSIONS] 

Transcriptions of some Symposia 
sessions. 

f.SIXEL] 

A program to convert ReGIS to 
SIXEL. 

[.SYSMGR] 

VI. 

[.ROTH] 

DTR definitions for Disk Quotas. 
SYSUAF, etc.; procedures to record 
user login history and terminal /line 
usage. 

[.LG02] 

Allows use of available fonts resi¬ 
dent in LG02 line printer with ALL- 
IN-1. 

[.PENDING] 

Shows ALL-IN-1 PENDING file 
by user-specified number of pend¬ 
ing messages. 

f.RMN] 

An ALL-IN-1 Multiple Read for 
mail which allows users to read new 
mail sequentially and answer, print, 
or delete it as they read. 

[.TM PRINT) 

Allows ALL-IN-1 user to specify a 
window of time (rather than the 24 
hour default window) for printing 
week’s schedule and calendars. 

[.TODO] 

Sorts “to do” list in ALL-IN-1 by 
priority and number; results may 
be displayed or printed. 


Media (Service Charge Code): 2400’ Magnetic Tape (PS) For¬ 
mat: VMS/BACKUP. TK50 Tape Cartridge (TC) Format: VMS/ 
BACKUP 


DECUS No: VAX-323 Title: Systems Services Version: 

March 1988 

Submitted by. David N. Mitchell, Information Systems & Net¬ 
works, Inc., Durham, NC 

Operating System: VAX/VMS V4.5 Source Language: C, VAX 

FORTRAN Keywords: System Management - VMS, Utilities- 

VMS 

Abstract: This package contains the following programs: 

CRELNM.C Theprogram utilizes system services to create 

a logical name and place it in one of the pro¬ 
cesses logical name tables. Theprogram should 
be passed the name of the logical name table 
where the logicalwill be placed, the logical 


name to be set and the equivalence 
which the logical will be equated. T r 
which are included in the progran 
eessary: 

• “descrip.h” which holds the stru' 
the necessary descriptors. 

• “lnmdef.h" which holds definitior 
logical name flags. 

• “psldef.h” which contains the ace 
definition to be used. 

The descriptors for the logical name * 
the logical name are set up along 
single item list in which to return th- 
lence string. A final zeroed out item 
up and then the system service to trar 
logical is called followed by an error - 
to be printed if the call should fail. 
SNDJBCW.C The program utilizes system servic' 
and GETSJC mit command procedures to bate! 
DEF.FOR The program has four parameter 
into it: 

• The name of the procedure to be si > 

• The name of the queue to which i 
submitted 

• A string containing up to eight ar; 
to be passed to the submitted pr 
These eight parameters must be s' 
by commas and the string mus‘ 
minated with a comma. All string 
to this routine must be null termir 
use with C functions. This progr 
written to be called by PL/1 and 
but should work with most any lanp 
long as the aforementioned requi • 
are followed. This program calls 
TRAN routine which includes the iv 
definitions for the send to job o' 
system service and the translate 
name system service The reaso 
necessary is because this definite 
not available in theC language.Th'*, 
sets up the necessary item list s! 
and enters the proper informatk' 
includes: 

• The queue name logical. 

• The procedure file specification log 
DCL procedure to be submitted). 

• The log file specification. 

• No log delete to prevent the log 
being erased. 

• No log spool to prevent the log 
being printed. 

•Job name to set the process narr 
submitted job. 

•Eight parameters. 

These routines can easily be modifi 
elude or exclude qualifiers required 
ticular application. 

TRNLNM.C The program utilizes system service 
slate logical names. The program 
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the address of the character array containing 
the logical name to be translated .This array 
must be declared in the calling program to be 
256characters. This is the maximum possible 
length of an equivalence string. If the array is 
smaller, there is a possibility of over-writing 
other variables in memory. Two include files 
are necessary : 

♦ “descriph" which holds the structures of 
the necessary descriptors. 

• “lnmdefh” -which holds definitions for the 
logical name flags. 

The descriptors for the logical name table and 
the logical name are set up along with the 
single item list in which to return the equiva¬ 
lence string .A final zeroed out item list is set 
up and then the system service to translate the 
logical is called followed by an error message 
to be printed if the call should fail. 

Notes: A FORTRAN routine had to be called in order to get 
the 

“Send To Job Controller” MACRO difinitions. Digital Equip - 
ment Corporation has not converted these definition files to the 
C Language. 

Documentation not available. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) For¬ 
mat VMS/BACKUP 

DECUS No: VAX-324 Title: TPU Hebrew Functionality Ver¬ 
sion: 1, January 1988 

Submitted by: Digital Equipment Corporation 

Operating System: MicroVMS V4.6, VAX/VMS V4.6 Software 
Required: TPU English versionHardware Required: Printer 
and terminals to support Hebrew option. Keywords: Editors 

Abstract VAX users who find themselves with a need to be able 
to easily create/edit text files in Hebrew yet do not require 

sophisticated word processing capabilities will find H_EDIT a 

reliable solutioa 

H_EDIT is a TPU based editor which enables the user to 

create/edit Hebrew text files. It allows for the typing of text 
from either right_to_left or left_to_right Direction switch¬ 

ing is accomplished by simple keystrokes. 

H_EDIT utilizes the EDT style Keypad Emulator and func¬ 

tionality. 

Notes: Terminals must contain Hebrew firmware for this pro¬ 
gram to perform properly. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) For¬ 
mat VMS/BACKUP 

DECUS No: VAX-325 Title: RDB Report Writer Version: 1, 
March 1988 

Submitted by: David Cohen, Security Pacific Automation Co. 
W29-50, Los Angeles, CA 

Operating System: VAX/VMS V4.5 Source Language: DCL, 
VAX COBOL Software Required: COBOL Keywords: Tools - 


Applications Development Abstract: This package can gener¬ 
ate a COBOL subprogram (with a linkage section) which can be 
called from an RCO program. The subprogram will handle all 
the report logic, including control breaks, totals, formatting, 
and creating the actual print file Accepts as input four user sup¬ 
plied files which define the report and the data file record. 
Validates input files. Handles up to eight levels of control breaks, 
with totals available for each level. Options include: 

• At Top of Control Group. 

• At Bottom of Control Group. 

• At Top of Page. 

• At Bottom of Report 

• New Page 

These terms have the same meaning as in DATATRIEVE. 
Grand totals are available Grand totals and "At Bottom of 
Report” are in addition to the eight allowable control breaks. 
Report column positions are computed automatically, from 
Layout Chart created by the user, in any editor. Output pro¬ 
gram can be edited and modified, if desired. 

The generated subprogram is designed to be called from an 
RCO program, once for every database record in the stream. 

Notes: Operating system VMS 4.0 and later is required. File¬ 
names are greater than nine letters. 

Media (Service Charge Code): User’s Manual (EA). 600’ Mag¬ 
netic Tape (MA)Format: VMS/BACKUP 


DECUS No: VAX-326 Title: Protect Version: 1.00, February 
1988 

Submitted by. Andre Baskin. SYSCON Corp. Williamsburg, 
VA 

Operating System: VAX/VMS V4.5 Source Language: C, 
MACRO-32 Keywords: Security 

Abstract Protect is a system to protect VMS executables from 
attack by computerviruses by detecting any tampering with the 
executable done by the virus. A virus is a program which has the 
ability to infect other programs by inserting a new section of 
code into another program. This new code will cause some harm 
to the system (ie., corrupt data, delete files, etc.). In addition, 
the code inserted by the virus will infect other programs, thus 
spreading itself throughout the system. Protect is able to pro¬ 
vide protection from computer viruses by signaling when the 
executable code of a program has been tampered with in any 
way. This is done by using the Protect program to place a stamp 
on the executable. This stamp will be used to check for any 
changes to the file and will in no way affect the program at run 
time. Once the program has been stamped by Protect there are 
two ways in which tampering can be detected. The first method 

is to include a call to the function check_program either in the 

initialization function used by LIBSIN1TIALIZE or in the first 
line of executable code. This function will return either “1” 
which means the program has not been tampered with, or “0” 
which means the program has been tampered with. In the case 
of a program for which the source code is unavailable, once it has 
been stamped by Protect, the program Check can be run and will 
set the symbol SSTATUS to either “1” if the executable has not 
been tampered with, or to “0” if the executable has been tam¬ 
pered with. 

Documentation may or may not be on magnetic media. Sources 
not included. 


Media (Service Charge Code): 600' Magnetic Tape (MA) For¬ 
mat VMS/BACKUP 


DECUS No: VAX-327 Title: YCU VAX/VMS Calendar Utility 
Version: 3.7. March 1988 

Submitted by: Michael C. Johnson. Spuds Software. Brookline. 
MA 

Operating System: MicroVMS V4.5, VAX/VMS V4.6 Source 
Language: VAX BASIC Memory Required: 350K Hardware 
Required: VT100. VT220 Terminals Keywords: Calendars 
Abstract VCU is an interactive perpetual calendar for the 
VAX/VMS operating system. It provides you with a simple way 
to store and retrieve messages for any day. 

Features include: 

• A complete pull-down menu system with command keys. 

• A display consisting of the time, date, previous month, current 
month, next month, day of the year, days left in the year, 
yearly messages, weekly message, and daily messages. 

• A search function. 

• Output capability. 

• On screen message editing. 

• Qualifiers and parameters to provide complete access from 
1DCL. 

• Toggling of the yearly, weekly, and daily message displays. 

• A full year display. 

• On-line help. 

Notes: Operating system VMS V4.0 or later is required, because 
the program utilizes system routines, screen management rou¬ 
tines, and utility routines. 

Sources not included. 

Media (Service Charge Code): User’s Manual (EA). 600’ Mag¬ 
netic Tape (MA) Format: VMS/BACKUP 

DECUS No: VAX-328 Title: SCOPY Version: 1.0. March 1988 
Submitted by: John T. Carroll III, Columbus, IN 

Operating System: MicroVMS V4.6 Source Language: VAX 
FORTRAN Hardware Required: VT200 or VT300 Terminal 
Keywords: FORTRAN, Graphics, ReGIS 
Abstract: SCOPY is a FORTRAN subroutine that transfers 
images displayed on Digital Equipment Corporation’s VT200 
and VT300 series graphics terminals to a plot file. The transfer 
is accomplished by initiating a remote screen copy and redirect 
ing the screen image from the printer port to the host The 
resulting plot file can be printed on any one of Digital Equip¬ 
ment Corporation’s graphics printers or rapidly redisplayed at 
the terminal 

Media (Service Charge Code): One RX50 Diskette (JA) For¬ 
mat VAX/ANSI, 600’ Magnetic Tape (MA) Format VAX/ 
ANSI 


NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PROFESSIONAL-300 SERIES OF COMPUTERS 


DECUS No: PRO-173 Title: SIXELPRINT Version: 2.22, 
July 1987 

Submitted by: Digital Equipment Corporation 

Operating System: P/OS V3.1 Source Language. PASCAL 
Memory Required: 512KB Hardware Required: LA50. LA75. 
LA100. LA210 OR LN03 printer Keywords: Graphics. Text 
Formatting 

Abstract SIXELPRINT and FONTEDIT are two applications 
which make up a publishing package for flyers, slides, front 
pages or even small documentations. 

SIXELPRINT formats text for output to any printer capable of 
handling sixel data. The input text is supplied by a file which 
you may create using your favorite editor. SIXELPRINT uses 
fonts supplied with the application or generated by FON¬ 
TEDIT, and creates a sixel file (SPRINT.SIX) containing the 
sequences which draw those characters on the printer. SIX¬ 
ELPRINT also knows how to do text justification, center, indent, 
underline and other document formatting operations. 

FONTEDIT is a special-purpose editor, used to create and edit 
font files which will be used by SlXELPRINT.lt allows the user 
to work with the way characters look and takes care of the 
encoding of the font in the language that printers understand, 
transparently to the user. 

The package includes seventeen ASCII fonts, three mul¬ 
tinational fonts, two numeric only fonts, two fancy fonts, a Digi¬ 
tal Equipment Corporation Logo font and a chess font The fonts 
come in sizes of 12.18. and 24 points (72 points = 1 inch). 

Notes: Operating system P/OS V3.0 or later is required. 

Media (Service Charge Code): User’s Manual (EA), Two RX50 
Diskettes (JB) Format: FILES-11 

NEW LIBRARY PROGRAMS AVAILABLE 
FOR THE 

PDP-11 COMPUTER FAMILY 

DECUS No: 11-902 Title: Routine Backup FacilitatorVersion: 
1.0, March 1988 

Submitted by: Richard Desper, Army Materials Technology 
Lab., Watertown, MA 

Operating System: RT-11 Vo.O Source Language: IND Memory 
Required: 56K Software Required: IND.SAV Keywords: Util¬ 
ities -Disk - RT-11 

Abstract: This pair of IND files, FULLBAK.COM and PAR- 
BAK.COM, smoothly leads you through RT-11 to perform disk 
backups. The two files perform the following tasks: 

FULLBAK.COM Writes full backups from a large disk (de¬ 
fault: DL0) to a magnetic tape unit (de¬ 
fault: MT0), supporting possible multi- 
Volume output 

PARBAK.COM Writes partial backups of the same large 
disk to a smaller removeable media disk 
(default: DY0), consisting of all files since 
the date of the last full backup. 
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Directory listings and dates of the most recent full and partial 
backups are maintained on DYO along with the most recent par¬ 
tial backup. Devices definitions may be changed readily by edit¬ 
ing the .COM files. More extensive comments are available in the 
file COMENT.LST. 

A separate removeable output disk (eg.. DYO) should be sup¬ 
ported for each device (e.g., DLO) to be backed up to receive data 
specific to that device. FULLBAK.COM AND PARBAK.COM 
may optionally reside on this disk as well. 

The partial backup will fail when the size of the partial backup 
exceeds a limit (about 900 blocks for DYO) on partial output 
device .The partial backup will not copy undated files, nor will it 
copy recent files within a logical disk file on DLO where the logi¬ 
cal disk file itself bears an earlier date. Also, the partial backup 
procedure temporarily defines logical disk LD3. causing poten¬ 
tial conflict with user definition of LD3. COMENT.LST offers 
remedies for all of these restrictions. 

Notes: Operating system RT-11 V5.0 or higher is required. 
Defines, uses logical disk LD3. 

Restrictions: Partial backups limited to size of partial backup 
volume Undated files not copied in partial backup. 

Media (Service Charge Code): One RX01 Diskette(KA) For¬ 
mat RT-11, 600’ Magnetic Tape (MA) Format RT-11 

NEW ULTRIX PROGRAMS 

DECUS No: UX-111 Title: PLAtools Version: November 
1987 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corporation 

Operating System: ULTRIX/UNIX Source Language: C, RAT- 
FOR Memory Required: 1.5MB Software Required: VAX C 
Compiler, RATFOR Compiler Keywords: Utilities - ULTRIX 

Abstract The Berkeley PLA Tools are a set of tools designed for 
performing logical and topological optimization as well as test 
pattern generation of programmable logic arrays (PLAs). The 
tools form a system encompassing the design of PLAs from the 
specification of algebraic equations, through logic minimization 
and folding, to final physical layout and test pattern generation. 
These tools also support the optimization of finite-state machines 
(FSMs) when the machine is implemented as a programmable 
logic array. 

Notes: Operating system UNIX V4.1, V4.2, or V4.3BSD is re¬ 
quired. This program was developed by the Computer-Aided 
Design Group, Department of Electrical Engineering and Com¬ 
puter Sciences. University of California-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): User’s Manual (EE). 600* Mag¬ 
netic Tape (MA) Format TAR 


DECUS No: UX-112 Title: SPLICE3 Version: 3.0. March 
1988 

Submitted by: University of California at Berkeley, through 
Digital Equipment Corp. 

Operating System: ULTRIX/UNIX Source Language: C 
Memory Required: 1.5MB Software Required: VAX C Com¬ 
piler Keywords: Circuit Simulation 

Abstract SPLICE3 is a circuit simulation program for large- 
scale integrated circuits. It performs electrical simulation using 
event-driven selective-trace techniques. This analysis is done 
using the Iterated Timing Analysis (ITA) algorithm, which per¬ 
forms an accurate electrical waveform analysis up to fifty times 
faster than SPICE2. 

Release notes are distributed with each order. 

Notes: Operating system UNIX V4.2 or V4.3BSD is required. 
This program was developed by the Computer-Aided Design 
Group, Department of Electrical Engineering and Computer 
Sciences, University of California-Berkeley. 

Restrictions: U.S. Government export regulations prohibit the 
distribution of this program outside the United States without 
the appropriate export licenses. 

Media (Service Charge Code): User’s Manual (EE). 600’ Mag¬ 
netic Tape (MA)Format: TAR 

REVISIONS TO LIBRARY PROGRAMS 

DECUS No: ll-SP-47 Title: AnalytiCalc (PortaCalc): A 3D 
Spreadsheet/Database System Version: V22.3B. March 1988 

Author Glenn C. Everhart, Ph.D. 

Operating System: AMIGA DOS, IAS, MS/DOS. MicroVMS, 
RSX-11M. RSX-11M-PLUS, VAX/VMS Source Language: 
FORTRAN 77, MACRO-11, MACRO-32 Keywords: Business 
Applications, Data Base Management Mathematical, Por¬ 
taCalc, Spreadsheet 

Abstract AnalytiCalc is a powerful three dimensional spread- 
sheet/database and analysis system with easy user exten¬ 
sibility designed to outperform most any commercial package 
available, running on PDP-11 systems able to support the F4P 
compiler, or VAX systems, needing the VAX FORTRAN com¬ 
piler to compile Several terminals are supported, including the 
VT100 series, VT52, Datamedia Colorscan 10 and Elite 1500, 
Televideo 925, and ANSI color terminals. A full DTR-32 inter¬ 
face is supported on VAX and a command mode structure similar 
to Visicalc or other micro spreadsheets is available as an option. 
Address range maxima are 32,000 rows and 32.000 columns on 
VAX, 10,000 by 10.000 on PDP-11 (using software virtual memory 
on PDP-11). A mode for “connecting” arbitrary' VAX appli¬ 
cations to AnalytiCalc is with simple syntax and numerous sup¬ 
porting new string functions. 

The program is designed for power, and to be easily portable to 
other systems supporting FORTRAN, with peculiarities used 
documented, and its manual is designed to be turned into a sys¬ 
tem HELP file so that it can be read online Tutorials are sup¬ 
plied as well. 

A data management system interface is built in. permitting 
spreadsheets to access a potentially unlimited number of files 


and records or parts of records in those files for user defined 
functions, numbers, formulas, text or whatnot. In fact it has 
many of the attributes of a language. Every cell may contain far 
more complex formulas than most commercially sold programs, 
and indeed may be a complete program with the ability to 
execute most command-level spreadsheet commands, though 
with minor restrictions. 

Merging of multiple sheets, matrix algebra, general function 
solving (a la TKISOLVER. though with a less polished user 
interface), and easy document load/unload make this spread¬ 
sheet very significantly more powerful than all but the most 
elaborate mainframe packages, and infinitely easier to cus¬ 
tomize User commands may be entered via keyw’ord or function 
key and are provided with a comprehensive HELP system per¬ 
mitting users to individually tailor commands to their needs. 

A powerful text integration function permits integration of 
word processing files with reports, permitting use of AnalytiCalc 
(PortaCalc) to integrate sections of reports which are edited 
with any editor. It also simplifies inserting text from external 
files flexibly over null cells of the spreadsheet 

This package runs on PDP-11, or on VAX in NATIVE MODE. 
Versions have been built for RSX-11M, RSX-11M-PLUS, VMS, 
and RSTS. though supplied build files are for the RSX and VMS 
versions only. Speed of the VAX versions is higher than many of 
the expensive commercial VAX versions. An AMIGA and a MS/ 
DOS version of AnalytiCalc are presented here also. 

Several new trig functions and some bulletproofing corrections 
have been added to this version, plus some new' code speed- 
ups. 

The ability to call UNMODIFIED FORTRAN callable sub¬ 
routines (plus a few hundred example routines) has been added, 
and performance for really huge VAX sheets has been improved 
via better hashing methods. It is now' trivial to add almost any 
desired functionality to AnalytiCalc. 

SPECIAL HARDWARE: On VAX, screen-independent cur¬ 
sor routines are used for screen addressing normally. On PDP- 
11, the software must be built for the appropriate terminal. 
Versions of the UVT100 subroutine for VT100, VT52. Datamedia 
Elite, and several other types of terminals including VT100 with 
Advanced Video and Colorscan 10 are supplied, w'ith command 
files for most combinations. The VT52 versions will show what 
the minimum requirements are for control. Most any terminal 
can be easily interfaced to the package by editing one of the 
UVT100 routines to correspond to the terminal’s control se¬ 
quences, provided direct cursor addressing is supported. 

Release Notes are distributed w’ith each order. 

Notes: VAX/VMS users see DECUS No. V-SP-24. 

Changes and Improvements: Faster VAX, Amiga versions. 
VAX version can now call any unmodified FORTRAN callable 
subroutines. 

Media (Service Charge Code): 2400’ Magnetic Tape(PC) For¬ 
mat RMSBCK, TK50 Tape Cartridge (TC) Format RMSBCK 


DECUS No: V-SP-24 Title: AnalytiCalc (PortaCalc): A 3D 
Spreadsheet/Database System in VMS/BACKUP Version: 
V22.3B. March 1988 

Author Glenn C. Everhart, Ph.D. 


Operating System: AMIGA DOS, IAS, MS/DOS. RSX-11M. 
RSX-11M-PLUS, VAX/VMS Source Language: FORTRAN 77. 
MACRO-11. MACRO-32 Keywords: Business Applications. 
Data Base Management. Mathematical, PortaCalc. Spread¬ 
sheet 

Abstract AnalytiCalc is a powerful three dimensional spread- 
sheet/database and analysis system with easy user exten¬ 
sibility designed to outperform most any commercial package 
available, running on PDP-11 systems able to support the F4P 
compiler, or VAX systems, needing the VAX FORTRAN com¬ 
piler to compile. Several terminals are supported, includingthe 
VT100 series, VT52, Datamedia Colorscan 10, and Elite 1500, 
Televideo 925. and ANSI color terminals. A full DTR-32 inter¬ 
face is supported on VAX and a command mode structure similar 
to Visicalc or other micro spreadsheets is available as an option. 
Address range maxima are 32.000 rows and 32,000 columns on 
VAX, 10,000 by 10.000 on PDP-11 (using software virtual 
memory on PDP-11). A mode for “connecting” arbitrary VAX 
applications to AnalytiCalc is now' available also with simple 
syntax and numerous supporting new string functions. 

The program is designed for power and to be easily portable to 
other systems supporting FORTRAN, with peculiarities used 
documented, and its manual is designed to be turned into a sys¬ 
tem HELP file so that it can be read online. Tutorials are sup¬ 
plied as well 

A data management system interface is built in, permitting 
spreadsheets to access a potentially unlimited number of files 
and recordsor parts of records in those files for user defined 
functions, numbers, formulas, text or w'hatnot. In fact, it has 
many of the attributes of a language. Every cell may contain far 
more complex formulas than most commercially sold programs, 
and indeed may be a complete program with the ability to 
execute most command-level spreadsheet commands, though 
w'ith minor restrictions. 

Merging of multiple sheets, matrix algebra, general function 
solving (a la TKISOLVER, though with a less polished user 
interface), and easy document load/unload make this spread¬ 
sheet very significantly more powerful than all but the most 
elaborate mainframe packages, and infinitely easier to cus¬ 
tomize. User commands may be entered via keyword or function 
key and are provided with a comprehensive HELP system per¬ 
mitting users to individually tailor commands to their needs. 

A powerful text integration function permits integration of 
word processing files with reports, permitting use of Analyti¬ 
Calc (PortaCalc) to integrate sections of reports which are edited 
w'ith any editor. It also simplifies inserting text from external 
files flexibly over null cells of the spreadsheet 

This package runs on PDP-11, or on VAX in NATIVE MODE. 
Versions have been built for RSX-11M, RSX-11M-PLUS, VMS 
and RSTS, though supplied build files are for the RSX and VMS 
versions only. Speed of the VAX versions is higher than many of 
the expensive commercial VAX versions. An AMIGA and a MS/ 
DOS version of AnalytiCalc are presented here also. 

Several new trig functions and some bulletproofing corrections 
have been added to this version, plus some new' code speedups. 

The ability to call UNMODIFIED FORTRAN callable sub- 
routines(plus afew T hundred example routines) has been added, 
and performance for really huge VAX sheets has been improved 
via better hashing methods. It is now trivial to add almost any 
desired functionality to AnalytiCalc. 
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SPECIAL HARDWARE: On VAX. screen-independent cur¬ 
sor routines are used for screen addressing normally. On PDP- 
11. the software must be built for the appropriate terminal. 
Versions of the UYT100 subroutine for VT100, VT52. Datamedia 
Elite and several other types of terminals including VT100 with 
Advanced Video and Colorscan 10 are supplied, with command 
files for most combinations. The VT52 versions will show what 
the minimum requirements are for control. Most any terminal 
can be easily interfaced to the package by editing one of the 
UVTIOO routines to correspond to the terminal’s control se¬ 
quences, provided direct cursor addressing is supported. 

Release Notes are distributed with each order. 

Notes: PDP-11 users see DECUS No. ll-SP-47. 

Changes and Improvements: Faster VAX, AMIGA versions. 
VAX version can now call any unmodified FORTRAN callable 
subroutines. 

Media (Service Charge Code): 2400’ Magnetic Tape (PC) For¬ 
mat: VMS/BACKUP, TK50 Tape Cartridge (TC) Format VMS/ 
BACKUP 

DECUS No: VAX-183 Title: JUICER Version: March 1988 
Submitted by: Michael N. LeVine, Naval Weapons Center, 
China Lake CA 

Operating System: VAX/VMS V4.X Source Language: MACRO- 
32 Software Required: RUNOFF Keywords: Utilities - Disk - 
VMS 

Abstract The JUICER package of programs and command files 
is provided to the system manager to allow him to monitor VAX/ 
VMS ODS-2 disks for disk and file fragmentation, disk usage 
and to do such compression as might be needed. The package is 
made up of eight parts: 

• JUICER_1 to do stand alone disk compression. 

• JUICER_2 to do online disk and file defragmentation while 

disk is in use by other users. 

• FRAG to monitor disk fragmentation. 

• FILE to monitor and optionally compress fragmented files. 

• DIR to make a map of disk directory structure and its file/ 
block usage. 

• DISK to show by user and account the number of disk blocks 
in use, authorized and overdraft. 

• DISKMON to run as a detached process to provide a constant 
monitor of all disk(s) free space 

• BAD to scan a selected disk for bad blocks and on user 
authorization, try to repair them. 

JUICER_1 is an inplace disk compression utility for VAX/VMS 
ODS-2 disks suffering from excessive fragmentation. This pro¬ 
gram. within limitations, attempts to move portions of files from 
the high end of the disk to any Unused areas (fragments) at the 
low end, freeing up larger contiguous free areas at the high 
end. 

JUICER_2 is an on-line in-place disk and file compression 
utility for VAX/VMS ODS-2 disks suffering from excessive 
fragmentation. This program runs on-line while other users are 
also using the disk. It defragments the most defragmented files 
it can find that will fit in the largest contiguous free areas on 
disk, and moves other files as far down toward the low end of the 
disk as it can. filling up free fragments at the low end and freeing 
up more space at the high end. 


FRAG is run on a disk to see how badly the target disk free space 
is fragmented, giving a histogram of fragmented areas by size, a 
calculated measure of the disk free space fragmentation and, if 
wanted, a map of free fragments by starting LBN vs size. 

FILE scans all the file headers on the target disk and outputs 
two list files, one containing a list of the 100 files havingthe most 
retrieval pointers in use. and the second being a matrix of file 
size versus number of pointersin use. The command file CON- 
TIG is used which reads one of the list files produced by FILE 
and running interactively with the user, converts the listed files 
from fragmented to contiguous. 

DIR scans a target disk and creates an output file DIREC- 
TORY.MAP containing a graphical output showing the on disk 
director)' structure, with a notation for each directory showing 
the number of files and blocks contained therein. 

DISK COM sets up data for the program DISKEXE which pro¬ 
duces a list by user and account (for each disk specified) of disk 
blocks in use, authorized and permitted overdrafts. 

DISKMON is a program that I found on a VAX SIG tape submit¬ 
ted by Eric Richards of Gould Ocean Systems, 18901 Euclid Ave, 
Cleveland, Ohio44117. It is a detached process which constantly 
monitors all disks on the system and warns when free space falls 
below preset values. 

BAD scans a selected disk for bad blocks. When a bad block is 
found, the user is asked if BAD should attempt to rewritethe 
block, assuming a soft error. If the rewrite is selected, the user 
can select to edit the contents of the bad block before the rewrite 
is attempted. 

Notes: JUICER_1 is Vl.13 and JUICER_2 is V2.17. 
Changes and Improvements: Bugfix to JUICER-2. 
Restrictions: Does not do volume setting. 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 


DECUS No: VAX-193 Title: VTEDIT: Keypad Text Editor 
and Corrector for VAXTPU Version: 4.5, January 1988 

Submitted by: Dr. Gerhard Week. Infodas GmbH, D-5000 Koeln 
71, West Germany 

Operating System: MicroVMS V4.5, V4.6, VAX/VMS V4.6 
Source Language: VAX FORTRAN, VAXTPU Memory Re¬ 
quired: Virtual Hardware Required: Digital Equipment Cor¬ 
poration ANSI Terminal (\T100, VT200, VT300 compatible) 
Keywords: Editors 

Abstract The Video Terminal Editor VTEDIT is an editing 
interface for the VAX Text Processing Utility VAXTPU, and 
optionally for VAX LSE. The VTEDIT interface is an efficient, 
keypad driven editor allowing multi-window editing and pro¬ 
viding semi-automatic, context dependent text formatting. 
VTEDIT implements, among others, the following features: 

• Multi-file and multi-buffer editing. 

• Split screen editing. 

• Insert and overstrike editing. 

• Free and bound cursor movement. 

• Recognition of all TECO match control constructs and access 
to VAXTPU pattern building constructs. 

• Journaling the editing session. 


• Access to the VMS operating system via DCL. SPAWN and 
Attach commands. 

• Access to VAXTPU. 

Many additional editor functions like: 

• Search and replace. 

• Rectangular cut paste, and delete. 

• Remember and retrieve buffer positions. 

• Insertion of date. time, file and buffer names. 

• Case and position control for searches. 

• Case conversion and capitalization of words. 

• Center line and fill paragraph. 

• Control of tabulator setting. 

• Replace Tabs with spaces. 

• Deletion of trailing blanks. 

• Sorting of buffers and ranges. 

• Wildcard filename search and selection. 

• Selection of user and system buffers from a list. 

Optional semi-automatic, context dependent text formatting 
providing the following functions: 

• Case conversion/automatic case control 

• Automatic indentation. 

• Manual correction of indentation. 

• Automatic word wrap 

• Automatic line justification. 

• Optional automatic insertion of closing parentheses and str¬ 
ing delimiters. 

• Optional highlighting of the matching opening parenthesis 
and string delimiter. 

• Extensive online help. 

Optional access to the Language-Sensitive Editor VAX LSE, 
providing operations to: 

• Fill and align program comments. 

• Specify a directory search list 

• Retrieve sources from a CMS library. 

• Protect buffers against modification. 

• Move to and/or delete placeholders. 

• Expand tokens, routines, placeholders, and aliases. 

• Define aliases for use in later expansions. 

• Compile sources and review errors. 

• Locate errors and retrieve the corresponding source text 

• Load language definitions and environments at run time. 

• Access the LSE command interpreter directly. 

Optional access to the Source Code Analyzer VAX SCA, provid¬ 
ing operations to: 

• Find declarations of symbols. 

• List positions of variable declarations and/or references. 

• Retrieve corresponding sources. 

• Access the SCA command interpreter directly. 

Notes: Operating system VMS V4.4 or later is required. In¬ 
stallation via VMSINSTAL; needs at least 1600 blocks; may 
interface to VAX LSE (this requires additional 800 blocks). 

Changes and Improvements: Additional interfaces to VAX 
LSE and SCA 

Media (Service Charge Code): User’s Manual (EC), 600’ Mag¬ 
netic Tape(MA) Format VMS/BACKUP 


DECUS No: VAX-214 Title: NEWS Version: 5.1, March 1988 

Submitted by: Geoff Huston. Australian National University, 
Canberra City, A.C.T. Australia. 2601 

Operating System: MicroVMS V4.6. VAX/VMS V4.6 Source 
Language: C Keywords: Bulletin Board 

Abstract NEWS is a software product which manages user, 
system and network news items. The news items are a set of text 
files which have been posted on the system for general public 
view. 

NEWS complies with the USENET Standard for Interchange of 
Messages, Request For Comment (RFC) 1036. The program 
includes network management (for inclusion of a VAX node into 
the USENET NEWS network), local news data management 
and screen-based user presentation modules. The release also 
includes a DECNET implementation of the Network News 
Transfer Protocol (NNTP), as defined in RFC 977, allowing 
server/client configurations of NEWS. 

The program supports similar functionality to that of the rnews 
(b2.11) and related USENET news readers as well as Digital 
Equipment Corporation’s VAXNOTES. 

Changes and Improvements: Compiles with Usenet RFC 1036. 

Media (Service Charge Code): 600’ Magnetic Tape (MA) For¬ 
mat* VMS/BACKUP, or order VAX-LIB-6 

DECUS No: VAX-297 Title: ReGIS to HPGL Conversion Pro¬ 
gram Version: 2.K February 1988 

Submitted by: Dr. N.S. Hoult, Racal Research Ltd., Reading, 
Berkshire. EnglandRG2 OSB 

Operating System: VAX/VMS V4.5, V4.6 Source Language: 
DCL, VAX FORTRAN Memory Required: 36KB Software 
Required: FORTRAN run-time system Keywords: Graphics, 
Hewlett Packard, ReGIS 

Abstract This program converts a file of ReGIS graphics com¬ 
mands, as used by the VT125 and VT240 terminals, into Hewlett 
Packard Graphics Language (HP-GL), as used on the 7580B 
plotter. It sends them to a file or directly to the plotter, which 
may be connected “in-line” with the terminal. Other plotters 
w’hich accept HP-GL may be accommodated by slight changes 
to the initialization sequences. All ReGIS commands are parsed, 
but only a subset (sufficient for line graphs with labelling, and 
including macrographs) is sent to the plotter. The resulting 
graphs may be scaled to fit the paper, or specified explicitly as 
Al. A2, etc., or in mm. The program is designed to facilitate the 
addition of extra ReGIS commands. 

Changes and Improvements: Mixed absolute and relative coor¬ 
dinates are allowed. 

Restrictions: Not all ReGIS commands are interpreted, although 
all are accepted. 

Documentation may or may not be on magnetic media 
Media (Service Charge Code):600’ Magnetic Tape (MA) For¬ 
mat: VMS/BACKUP 
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DECUS No: VAX-314 Title: VAX Capacity Management Tool 
Version: 3.1, April 1988 

Submitted by: Digital Equipment Corporation 

Operating System: VAX/VMS V4.3 - V4.6 Source Language: 
MACRO-32, VAX BASIC Memory Required: 102KB Software 
Required: VAX RETOS if hardcopy graphs to spooled sixel 
printers is required. Hardware Required: VT240 Terminal, 
VT330 Terminal or VT340 Terminal Keywords: System Man¬ 
agement - VMS 

Abstract: This system is designed as a tool for use by those peo¬ 
ple responsible for capacity management of a VAX or VAXclus- 
ter. It is not necessary to have VMS internal knowledge or 
system management knowledge to make use of this package. It 
is mainly designed for medium or large scale VAX installations. 

This package collects statistics on the utilization of CPU, memory 
and disk devices on the monitored VAX or VAXcluster. It also 
collects information on the CPU response of the machine and the 
number of processes executing. In addition to the VAX wide and 
VAXcluster wide information collected, this package also col¬ 
lects information for each UIC group. If your VAX system is 
arranged with each application in a separate UIC group then 
this allows the total system utilization to be broken down by 
application. 

The information collected can be displayed in a graphic form on 
VT240, VT330 or VT340 terminals. The capacity manager uses 
an interactive display program that has a DCL-like command 
syntax. The user can display histograms or frequency diagrams 
with hourly, daily or monthly information. The UIC group 
statistics can be added or subtracted from system wide statis¬ 
tics so graphic answers to questions like, “What will happen to 
the system if I take that application off?”, can be seen. 

Hardcopy output to printers that handle ReGIS is possible. If 
the Digital Equipment Corporation product RETOS is avail¬ 
able, output to printers like the LA100 that support sixel 
graphics can be performed. 

A machine uptime subsystem is included which records VAX 
uptime accurate to five minutes. These statistics can be repor¬ 
ted between date ranges, hour ranges and weekends can be 
either included or excluded from the calculatioa 

Complete user documentation, help text and installation do¬ 
cumentation is included on the media 

Changes and Improvements: Correction to MASSBUS disk 
statistic collectioa 

Media (Service Charge Code): 600’ Magnetic Tape(MA) For¬ 
mat VMS/BACKUP 


DECUS No: 11-462 Title: TERM.FOR Version: 5.0, March 
1988 


Submitted by: Richard Desper, Army Materials Technology 
Lab., Watertowa MA 

Operating System: RT-11 V5.0 Source Language: FORTRAN 
I\' Memory Required: 56KB Hardware Required: LSI-11 with 
DLV-11J (Standard MINC Hardware) Keywords: Data Com¬ 
munications, Emulators 


Abstract TERM is a program written in FORTRAN to convert 
a PDP-11/23 with a DLV-11J Quad Serial Interface into a smart 
terminal. The program allows the PDP-11/23 console terminal 
to converse with a remote computer. Disk files on the PDP-11/23 
may be accessed as either sources or sinks for ASCII data files. 
File transfer is limited to ASCII files and is not automatically 
checked for errors, but is quite reliable at speeds up to 2400 
baud. (A second speed limitation is that the remote computer 
baud rate must be slower than the PDP-11/23 console terminal 
rate. 9600 baud at this installation.)TERM is sufficiently trans¬ 
parent to the user to allow editing operations on the remote com¬ 
puter. eg. VAX/VMS EDT using VT100 or VT200 terminal 
support. For possible use with a remote VAX, a VMS file 
TERM.COM is also provided to facilitate file transfer. Further 
details are in the file TERM.DOC and as comments in TERM.- 
FOR. 

Notes: Operating system RT-11 V5.0 or higher is required. 
Multi-terminal support is required. Bold and reverse video con¬ 
trols of VT100 or VT200 terminals are used. VT100 or VT200 
support is not essential. High speed ring buffer support in RT- 
11 is highly recommended. 

Changes and Improvements: Run-time control of file transfer 
Echo, automatic control-Z termination of transmit files, added 
VMS TERM.COM file for easy conversation with VAX, trans¬ 
parency to EDT Editor controls. 

Restrictions: Record length 132 characters: ASCII Files only. 

Media (Service Charge Code): One RX01 Diskette (KA) For¬ 
mat: RT-11, 600’ Magnetic Tape (MA) Format: RT-11 
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STEERING COMMITTEE LISTS 



ARTIFICIAL INTELLIGENCE SIG 

CHAIR 

Cheryl Jalbert 
JCC 

128 West Broadway 
Granville, OH 43023 

(614) 587-0157 

VICE-CHAIR 

OPS5 WORKING GROUP CHAIR 

Don Rosenthal 
Space Telescope Science Inst 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

NEWSLETTER TASK FORCE CHAIR 
ADMINISTRATIVE ASSISTANCE 

Becky Wise 
Amdalh CSD 

2200 North Greenville Ave. 

Richardson, TX 75081 
(214) 699-9500 x 272 
NEWSLETTER EDITOR 
Terry Shannon 
Computer Info. Sys., Inc. 

Technical Consultant 
165 Bay State Drive 
Braintree, MA 02184 
(617) 848-7515 

SYMPOSIA COORDINATOR 

Pam Vavra 

Hughes Aircraft EDSG 
P.O. Box 902 E52/D220 
El Segundo, CA 90245-0902 
(213) 616-7071 

MEMBERSHIP COORDINATOR 
SUITE COORDINATOR 

Chris Goddard 
Simpact Associates 
9210 Skypark Court 
San Diego, CA 92123 
(619) 565-1865 

SESSION NOTE EDITOR 

George Humfeld 
Naval Sea Systems Command 
PMS 350 ED Dept of the Navy 
Washington, DC 20362-5101 
(202) 692-0137 

ASS’T SESSION NOTES EDITOR 
David Frydenlund 
STORE REPRESENTATIVE 
Sally Townsend 
Inst. Defense Analysis 
1801 N. Beauregard St. 

Alexandria, VA 22311 
(?03) 845-2122 

PUBLIC DOMAIN SOFTWARE TF CHAIR 
LIBRARY REPRESENTATIVE 

Jim Sims 

Space Telescope Science Ins. 

3700 San Martin Drive 
Baltimore, MD 21218 
(301) 338-4949 

AI LUG COORDINATOR 
ASSISTANT STORE REP. 

Dennis Clark 
RT2 Box 264 
Kingston, TN 37763 

(615) 576-7384 

REPORTER TO THE UPDATE.DAILY 
Bill Lennon 


SEMINAR UNIT REP. 
CAMPGROUND COORDINATOR 

Leona Fluck 

Educational Testing Service 
Rosedale Road 
Princeton, NJ 08540 
(609) 734-1243 
DEC COUNTERPART 
Art Beane 
Hudson, MA 

MEMBERS-AT-LARGE 
David Slater 
George Winkler 
Jeff Fox 

John Williamson 

Wayne Graves 

Matt Mathews 

Dave Campbell 

Shirley Bockstahler-Brandt 

Barry Breen 

Tom Viana 



BUSINESS APPLICATIONS SIG 

CHAIRMAN 

George Dyer 
Gallaudet University 
800 Florida Ave, NE-EMG Bldg 
Washington, DC 20002 
(202) 651-5300 

COMMUNICATIONS COORDINATOR 

Steve Lacativa 
Price Waterhouse 
153 East 53rd Street 
New York, NY 10022 
(212) 371-2000 x 3107 
SYMPOSIA COORDINATOR 
Mark Hults 

USSA Administrative Systems 
USSA Bldg. B01E 
San Antonio, TX 78288 
(512) 498-8725 
LUG COORDINATOR 
Patrick LeSesne 
U.S. Coast Guard 
Room 1416E 2100 2nd St SW 
Washington, DC 20593 
(202) 267-0354 

MARKETING COORDINATOR 

Tom Byrne 
L. Karp & Sons 
1301 Estes 

Elk Grove Village, IL 60007 
(312) 593-5706 

PROGRAM PLANNING COORDINATOR 

Stuart Lewis 
Douglas Furniture Corp. 

P.O. Box 97 

Bedford Park, IL 60499 
(312) 458-1505 

SEMINARS COORDINATOR 

Daniel Esbensen 
Touch Technologies, Inc. 

9990 Mesa Rm , Rd. #220 
San Diego, CA 92121 
(619) 455-7404 
LRP COORDINATOR 

Arnold I. Epstein 
D-M Computer Consultants 
Rolling Meadows, IL 60008 
(312) 394-8889 


NEWSLETTER EDITOR 

Dave Levenberg 
Credit Suisse 
Dept OA1 15th floor 
100 Wall Street 
New York, NY 10005 
(212) 612-8372 

SESSION NOTE EDITOR 

Marty Schmitt 
Harris Publishing 
3 Barker Avenue 
White Plains, NY 10601 
(914) 946-7500 x 287 
LIBRARY REPRESENTATIVE 
David Hittner 
Projects Unlimited 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 
CL SIG LIAISON 

Becky Burkes-Ham 

DMS SIG LIAISON Joe Sciuto MEMBERS-AT-LARGE 
Robert D. Lazenby 
Dixie Beer Dist, Inc. 

Louisville, KY 
Robert Kayne 
Gallaudet College 
Washington, DC 
Ray Evanson 
Paragon Data Systems 
Winona, MN 

DEC COUNTERPARTS 

Sue Yarger 

Digital Equipment Corporation 
Merrimack, NH 03054-0430 
Paula Daley 

Digital Equipment Corporation 
Merrimack, NH 03054-0430 
Pam Kukla 

Digital Equipment Corporation 
Maynard, MA 01754 


Wombat Magic 



DATATRIEVE/4GL SIG 

CHAIRMAN 

Donald E. Stern Jr. 

Warner Lambert Company 
10 Webster Road 
Milford. CT 06460 
(203) 783-0238 

SYMPOSIA COORDINATOR 

Lisa M. Pratt 
Vitro Corporation 
Nuwes Code 3144 
Keyport, WA 98345 
(206) 396-2501 

ASST SYMPOSIA REPRESENTATIVES 

T.C. Wool 

E.I. duPont DeNemours & Co. 
Engineering Dept. 

P.O. BOX 6090. 

Newark, DE 19714-6090 
(302) 366-4610 
Janet G. Banks 
Weyerhaeuser Info. Sys. 

Mail Stop CCB-2E 
Tacoma, WA 98477 
(206) 924-4082 
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COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Joe H. Gallagher 
Research Medical Center 
2316 East Meyer Blvd. 

Kansas City, MO 64132 
(816) 276-4235 

COMMUNICATION REPRESENTATIVE 
PRODUCTION EDITOR 

Steve Cordiviola 
Kentucky Geological Survey 
311 Breckinridge Hall 
Lexington ,KY 40506 

(606) 257-5863 

ASSOCIATE NEWSLETTER EDITOR 

Pasquale (Pat) F. Scopelliti 
Corning Glass Works 
Mail Stop MP-RO-01-1 
Coming, New York 14831 

(607) 974-4496 
Lorey B. Kimmel 
Digital Equipment Corp. 

6707 Whitestone Road 
Baltimore, MD 21207 
(301) 298-1500 
Herbert G. Reines 

Reznick Feddder & Silverman 
4520 East West Highway 
Suite 300 

Bethesda, MD 20814 
(301) 652-9100 
Alan Winston 

Stanford Synchrotron Radiation Lab. 
SLAL BIN 69 
P D .Box 4349 
Stanford, CA 94305 
(415) 854-3300 x2874 
VOLUNTEER COORDINATOR 
Susan Krentz 
NKF Engineering 
12200 Sunrise Valey Dr. 

Reston, VA 22091 
(703) 620-0900 

ASSISTANT VOLUNTEER COORD. 

Harry Miller 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 

SEMINARS COMMITTEE REP. 

Dana Schwartz 
15719Millbrook Lane 
Laurel, MD 20707 
(301) 859-6277 

SESSION NOTES EDITOR 

Bernadette Reynolds 
City of Ontario Police 
200 N. Cherry Avenue 
Ontario, CA 91764 
(714) 988-6481 
SUITE COORDINATOR 
Bert Roseberry 
Commandant (G-APA-1) 

2100 2nd Street, S.W. 

Washington, DC 20593-0001 
(202) 267-2629 
FEATURE EDITOR 

Philip A. Naecker 
Consulting Engineer 
3011 N. Mount Curve Ave. 

Altadena, CA 91001 
(818) 791-0945 
DEC COUNTERPARTS 

Mary Ann Fitzhugh 
110 Spit Brook Road 
ZK2-2/M 28 
Nashua, NH 03060 
(603) 881-2329 

ARTIST & LIBRARY REP. 

Bart Z. Lederman 
WU World Communications 
67 Broad Street (28th Floor) 

New York, NY 10004 
(212) 607-2657 


RALLY WORKING GROUP CHAIR 

Steven G. Fredrickson 
Fredrickson Consulting Service 
107 1st Avenue N. 

Seattle, WA 98109 
(206)283-0273 

POWERHOUSE W/G CHAIR 
David Nagurney 
TSO Financial Corp. 

Five TSO Financial Center 
Three Hundred Welsh Road 
Horsham, PA 19044-2009 
(215) 657-4000 
DMS SIG LIAISON 
William Tabor 
W.I. Tabor, Inc. 

12018 Royal Palm Blvd. 

Coral Springs, FL 33065 
(305) 755-7895 

SMARTSTAR WORKING GROUP CHAIR 

Thomas Colati 
Time Enterprises 
301 North Harrison 
Suite 101 

Princeton, NJ 08540 
(800) 548-6865 

ACCENT-R USER GROUP LIAISON 
Winston Tellis 
Fairfield University 
North Benson Road 
Fairfield, CT 06430 
(203) 255-5411 

FOCUS WORKING GROUP CHAIR 

Les Hulse 

The Gillette Company 
Prudential Tower Bldg. 

Boston, MA 02199 
(617) 421-7910 



DAARC SIG 

CHAIRMAN 

James Deck 

Inland Steel Research Lab. 

3001 East Columbus Drive 
East Chicago, IL 46312 
(219) 392-5613 

SYMPOSIA COORDINATOR 

Mack Overton 
FDA 

Chicago, IL 

COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 

Dale Hutchison 
Cummins Engine Co. 

4720 Baker St, Ext 
Lakewood, NY 14750 
(716) 456-2191 
DEC COUNTERPART 
Bill Forbes 
Marlboro, MA 


HARDWARE & INTERFACING 
Peter Clout 

Los Alamos National Lab 
Los Alamos, NM 

MATH STATISTICS & ANALYSIS 
Herbert J. Gould 
C.C.F.A. Univ. of Ill. Medical Ctr. 

Chicago, IL 

PROCESS CONTROL-INDUSTRIAL AUTOMATION 
Bill Tippie 

Kinetic Systems Corp. 

Lockport IL 

RS-1 

George Winkler 
CPC International 
Argo, IL 



DATA MANAGEMENT SYSTEMS SIG 

CHAIRMAN 

Doug Dickey 

GTE Government Systems 
1700 Research Blvd. 

Rockville, MD 20850 
(301) 294-8462 
MEMBER AT LARGE 
Alan Schultz 

Southwestern Bell Yellow Pages 
12800 Publication Dr., Suite 108 
St Louis, MO 63131 
(314) 957-2029 

SYMPOSIA COORDINATOR 
SQL Standards Rep. 

Keith Hare 
JCC 

P.O. Box 463 
Granville, OH 43023 
(614) 587-0157 

COMMUNICATIONS REP. 

Debbie Kennedy Coleman 
Shane Co. 

2 W Washington St, Suite 600 
Indianapolis, IN 46204 
(317) 635-9100 
NEWSLETTER EDITOR 
William Packard 
Mass Mutual Life Ins. 

1296 State Street B-391 
Springfield, MA )1111 
(413) 788-8411 

SESSION NOTE EDITOR 
Mark Morgan 
Farm Credit Banks 
P.O. Box 141 
Springfield, MA 01102 
(413) 786-7600 

MEMBERSHIP COORDINATOR 
MEMBER AT LARGE 
Rocky Hayden 
Userware International 
2235 Meyer Avenue 
Escondido, CA 
(619) 745-6006 
MEMBER AT LARGE 
PAST SIG CHAIRMAN 
Steve Pacheco 
Ship Analytics 
North Stonington, CT 06359 
(203) 535-3092 
PAST SIG CHAIR 
MEMBER AT LARGE 
Joe Sciuto 
U.S. Army 

5910 Westchester Street 
Alexandria, VA 22310 
(202) 692-6903 
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SEMINAR REP. 

Stephen Gomez 
Signal Technology 
1700 Montgomery St. 

San Francisco, CA 94111 
(415) 954-8532 

WORKING GROUP COORDINATOR/ 

Jim Perkins 
PSC, Inc. 

20 Kimball Ave., Suite 305 
Shelburne, VT 05401 
(802) 863-8825 

CAMPGROUND COORDINATOR 

Rosemary O’Mahony 
Arthur Anderson & co. 

33 West Monroe Street 
Chicago, IL 60603 
(312) 507-6510 

SESSION CHAIR COORDINATOR 

Andy Menezes 
AD & E 

29-B Montvale Avenue 
Woburn, MA 01801 
(617) 938-1979 

Rdb WORKING GROUP Coordinator 

Howard Cheng 

Bechtel Western Power Corp. 

12440 East Imperial Highway 
Norwalk, CA 90650 
(213) 807-4077 

ROADMAP COORDINATOR 

Elizabeth Irving 

Dupont 

P.O. Box 1089 

Orange, Texas 77630-1089 

(409) 886-9427 

DBMS COORDINATORS 

Bryan Holland 
1006 Pleasant St, #20 
Weymouth, MA 02189 
(617) 335-7573 
Paul E. Reese 
Aetna, Systems Dept 
Financial Division 
CityPlace 

Hartford, Connecticut 06156 
(203) 275-2012 
MEMBER AT LARGE 
Jim Redfield 
BDM 

9020 N. Cap. of Texas Highway 
Austin, TX 78759 
(512) 346-6760 

STORE REPRESENTATIVE 
FIMS STANDARDS REP. 

Paul W. Plum, Jr 
Lukens Steel Company 
Coatesville, PA 19320 
(215) 383-2024 

RMS WORKING GROUP COORDINATOR 

Allen Jay Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
DEC COUNTERPART 
Wendy Herman 
John Wood 
Nashua, NH 



EDUSIG 

CHAIRMAN 

Robert A.Shive, Jr. 
Mills aps College 
Jackson, MS 39210 
(601) 354-5201 


SYMPOSIA COORDINATOR 

Mary Jac Reed 
Off Comp Based Instruction 
University of Delaware 
305 Willard Hall 
Newark, DE 19716 
(302) 451-8161 

COMMUNICATIONS REPRESENTATIVE 
Robert W. McCarley 
Millsaps College 
Jackson, MS 39210 
(601) 354-5201 
NEWSLETTER EDITOR 
Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft CA 93267 
(805) 763-4282 
PSS COORDINATOR 
VAX SYSTEMS SIG LIAISON 
Donald C. Fuhr 
Tuskegee Institute 
Tuskegee Institute, AL 36088 
(205) 727-8242 

ADMINSTRATIVE APPLICATIONS COORD. 

Dave Cothrun 
Taft College 
29 Emmons Pk Drive 
P.O. Box 1437 
Taft CA 93268 
(805) 763-4282 

SESSION NOTE EDITOR 

Paula Barnes 
Guilford College 
5800 West Friendly Avenue 
Greensboro, NC 17410 
(919) 292-5511 
DEC COUNTERPART 
Gary Finerty 
Marlboro, MA 

O Graphics 
Applications 

DECUS ~-jJCZEi 

GRAPHICS APPLICATIONS SIG 

CHAIRMAN 

Bijoy Misra 

Smithsonian Institution 
60 Gordon St, MS39 
Cambridge, MA 02138 
(617) 495-7392 

SESSION NOTE EDITOR 

Carol Schwob 
Florida Atlantic Univ. 

Bldg. 22, Room 106 
Boca Raton, FL 33431 
(305) 393-2640 

NEWSLETTER EDITOR (acting) 

OPEN 

ASSOCIATE NEWSLETTER EDITOR 
Charles D. Carter 
Huntington Alloys, Inc. 

Technology Dept 
P.O. Box 1958 
Huntington, WV 25720 
(304) 526-5721 

WORKSTATION WORKING GROUP COORD. 

Bob McCormick 

Video Communications, Inc. 

1325 Springfield Street 
Feeding Hills, MA 01030 
(413) 786-7955 

ENGINEERING GRAPHICS WORKING GROUP COORD. 

Eric Rehm 
Gonzaga University 
SPOCAD 
E 502 Boone 
Spokane, WA 99258 
(509) 484-6814 


COMMUNICATIONS REP 
NEWSLETTER EDITOR 

Robert Hays 
KMS Fusion 
3621 So. State Road 
Box 1567 

Ann Arbor, MI 48106 
LIBRARY COORDINATOR 
Mike McPherson 
Michigan University 
269 Engineering Bldg. 

East Lansing, MI 48824 
(517) 353-9769 

STANDARDS COORDINATOR 
OPEN 

VOLUNTEER COORDINATOR 
Dick McCurdy 
University of Florida 
Room 216, Larsen Hall 
Gainsville, FL 32611 
(904) 392-4915 
LIBRARY COMMITTEE 
James M. Turner 
Saber Technology 
San Jose, CA 
DEC COUNTERPART 
Jim Flatten 
Spit Brook, NH 
Rick Landau 
Marlboro, MA 

INFORMATION OFFICER 

Mike York 

Boeing Computer Services 
P.O. Box 24346 M/S 03-73 
Seattle, WA 98124 
(206) 342-1442 

SYMPOSIUM COORDINATOR 

Dottie Elliott 
Northrop Services Inc. 

P.O. Box 12313 

Research Triangle PK, NC 27709 
(919) 541-1300 

DATA DISPLAY WORKING GROUP COORD. 

Joy Williams 
Eaton Corp. 

P.O. Box 766 
Southfield, MI 48037 

HARD 

NEWS 

HARDWARE MICRO SIG 

CHAIRMAN 

Willian K. Walker 
Monsanto Research Corp. 

Miamisburg, OH 

PRODUCT PLANNING COORDINATOR 

George Hamma 
Synergistic Technology 
Cupertino, CA 

PRE-SYMPOSIUM SEMINAR COORDINATOR 

James R. Lindesmith 
Monsanto Research Corp. 

Miamisburg, OH 

COMMUNICATIONS COORDINATOR 

John G. Hayes 
Information Systems 
South Central Bell 
Birmingham, AL 
NEWSLETTER EDITOR 
Carmen D. Wiseman 
Digital Review 
Boston, MA 

SESSION NOTE EDITOR 
DAARC SIG LIAISON 
Bill Tippie 

Kinetic Systems Corp. 

Lockport, IL 
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STANDARDS COORDINATOR 
CAMAC WORKING GROUP COORDINATOR 
Peter Clout 

Los Alamos National Lab 
los Alamos, NM 
LUG COORDINATOR 
Gregg Giesler 
Los Alamos Science Lab 
Los Alamos, NM 
TOEM (CHIPS & BOARDS) 

Jack J. Peterson 
Horizon Data Systems 
Richmond, VA 

HHK (HARDWARE HINTS & KINKS) 

Wayne Kesling 
Monsanto Research Cor. 

Miamisburg. OH 
UNIBUS HARDWARE 
Ron Bogue 

LIV Aerospace & Defense Co. 

Dallas, TX 

PERFORMANCE MEASUREMENT COORD. 
William Wallace 
600 W. Washington Street 
Peoria, IL 

CSS COORDINATOR 
Pratap Gohel 
E.I. duPont 
Ingleside, TX 

NETWORKS SIG LIAISON 
Sandra Traylor 
Target Systems 
Yorba Linda, CA 
VAX SIG LIAISON 
Dave Schmidt 
5100 Centre Avenue 
Pittsburgh, PA 
UNISIG LIAISON 

Jim Livingston 
1 Results Way 
Cupertino, CA 
SITE SIG LIAISON 
Emily Kitchen 
A-H. Robins Co. 

Richmond, VA 
RT-11 SIG LIAISON 
Gary Sallee 

Sallee Software Consulting 
yorba Linda, CA 
RSX SIG LIAISON 
Hans Jung 
Associated Press 
New York, NY 
MEMBERS-AT-LARGE 
Mike Rembis 
American Dade 
Costa Mesa, CA 
Hans Dahlke 
Richland, WA 
Jim Cutler 
EDS Tower 
16533 Evergreen 
Southfield, MI 

DEC COUNTERPARTS TERMINALS 
Nina Abramson 
Maynard, MA 
TOEM (Chips & Boards) 

Art Bigler 
Marlboro, MA 



IAS SIG 

CHAIRMAN 

Alan Frisbie 

Flying Disk Systems, Inc. 

4759 Round Top Drive 
Los Angeles, CA 90065 
(213) 256-2575 
NEWSLETTER EDITOR 
Frank R. Borger 
Radiation Therapy 
Michael Reese Medical Center 
Lake Shore Drive @ 31st St 
Chicago, IL 60616 
(312) 791-2515 

WHIMS COORDINATOR 

Kathleen Anderson 
Eaton Information Management 
System Division 
Hampton, VA 
(804) 326-1941 
RSX LIAISON 

Ray French 

Boeing Computer Services 
Seattle, WA 
(206) 655-6228 
MEMBER-AT-LARGE 
Doug Reno 
Abbot Laboratories 
North Chicago, IL 
(312) 937-7504 
PAST CHAIRMAN 

Mike Robitaille 
Grumman - CTEC, Inc. 

6862 Elm Street 
McLean VA 22101 
(703) 556-7400 x431 
CHAIRMAN EMERITUS 
Bob Curley 

Division of Medical Physics 
University of Pennsylvania 
Philadelphia, PA 
(215) 662-3083 

SYMPOSIA COORDINATOR 

Lynda L. Roenicke 
Special Systems Branch 
Naval Ocean Systems Center 
271 Cataline Blvd Code 742 
San Diego, CA 
(619) 225-7569 

LIBRARY COORDINATOR 

Ted Smith 

The University of PA 
Philadelphia, PA 19101 
(215) 662-3500 
MEMBER-AT-LARGE 
Kerry Wyckoff 
Salt Lake City, UT 
DEC COUNTERPART 

Nancyfaye Autenzio 
Stow, MA 
(617) 496-9606 


LANGUAGES AND TOOLS SIG 

CHAIRMAN 

Sam Whidden 

American Mathematical Society 
201 Charles St 
P.O. Box 6248 
Providence, RI02940 
(401) 272-9500 
VICE CHAIR 

SYMPOSIA COORDINATOR 

Earl Cory 
Eaton Corporation 
31717 La Tienda Dr. 

Westlake Village, CA 91359 
(818) 706-5385 

STORE REPRESENTATIVE 
Chair, TECH. PROD OF DOC. W/G 
Howard Holcombe 
RCA 

Front & Cooper Sts. 

Camden, NJ 08055 
(609) 338-4946 
NEWSLETTER EDITOR 
ALT. CommComm REP. 

A1 Folsom, Jr. 

Fischer & Porter Co. 

E. County Line Rd. 

Warminster, PA 18974 
(215) 674-7154 

SESSION NOTES EDITOR 
Mark Katz 

GTE Government Systems 
100 First Avenue 
Waltham, MA 02154 
(617) 466-3437 

AUSTRALIAN L&TINTERFACE 
Gordon Brimble 
Bldg. 180 Labs Area 
Defence Research Centre 
Box 2151 GPO 

Adelaide, S.A. Australia 5001 
(61)(8)259-6119 

INTERSIG COORDINATOR 

Dorothy Geiger 
Wollongong Logistics Group 
49 Showers Drive #451 
Mountain View, CA 94040 
(415) 948-1003 
(415) 962-7160 
EUROPEAN METHODS 
L&TINTERFACE 
Bernd Gliss 
Max-Planck-Institute 
Heisenbergstra Be 1 
7000 Stuttgart 80, W. Germany 
(711) 686-0251 
PAST CHAIR 

PRODUCTIVITY TOOLS COORDINATOR 

Kathy Hombach 
Digital Equipment Corporation 
110 Spit Brook Rd., ZK03-3/Y25 
Nashua, NH 03062 
, (603) 881-2505 



DIAGNOSTIC 

George D. Cooke 
Maynard, MA 
STORAGE 

Marilyn Fedele 
Maynard, MA 

MSD (Micro Systems Develp.) 
Roy Rodgers 
Maynard, MA 
PRINTER PRODUCTS 
Frank Orlando 
Maynard, MA 

DECUS EUROPE LIAISON 
Hans Zoller 


CHAIR TECO WORKING GROUP 
Mark J. Hyde 

Advanced Computing Services 
209 Ardsley Drive 
DeWitt, NY 13214 
(315) 446-7223 

MEMBER, ANSI BASIC X3J2 STDS, COMM. 
STANDARDS COORD. 

PDP-11 REP. 

CHAIR, PDP-11 LAYERED PRODUCT W/G 

Stephen C. Jackson 
SCJ Consulting, Inc. 

7260 University Avenue N.E. 

Suite 105 

Minneapolis, MN 55432 
(612) 571-8430 
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CHAIR, CONFIG. MGMT. WORKING GROUP 
Mark Alan Kidwell 
Texas Instruments Inc. 

P.0. Box 869305 M/S 8435 
Plano, TX 75086 
(214) 575-3547 

DEVEL. COUNTERPART, PDP-11 SOFTWARE 
Joe Mulvey 

Digital Equipment Corp. .ZK01-3/J10 
110 Spit Brook Road 
Nashua, NH 03062-2642 
(603) 881-1218 

LISP/AI COORDINATOR 

Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4844 

LIBRARY REPRESENTATIVE 

SIG TAPE LIBRARIAN 

CHAIR, PUBLIC DOMAIN SOFTWARE W/G 

Tony Scandora 

Argonne National Laboratory 
CMT 205 

Argonne, IL 60439 
(312) 972-7541 

CHAIR, C WORKING GROUP 

James Maves 
Eaton Corp, IMSD 
31717 La Tienda Drive 
Box 5009 

Westlake Village, CA 91359 
(818) 706-5395 
COMMCOMM REP. 

Jay Wiley 
Bechtel Power Corp 
12400 East Imperial Highway 
Norwalk, CA 90650 

(213) 807-4016 

SESSION CHAIRS COORDINATOR 
BOF CHAIRS COORDINATOR 
SESSIONS QUALITY COORD. 

ALT. SYMPOSIUM COORD. 

Gary C. Lelvis 
IMSL 

2500 Park West Tower One 
2500 City West Blvd. 

Houston, TX 77042-3020 
(713) 782-6060 

CHAIR, FORTRAN WORKING GROUP 

Scott Krusemark 

8473 Daisywood Ave N.W. 

North Canton, OH 44720 
(216) 499-6251 

CHAIR, LOW LEVEL LANGUAGES W/G 
Gerald Lester 

Computerized Processes Unlim. 

2901 Houma Blvd. Suite 5 
Metairie, LA 70006 
(504) 889-2784 

DEVEL. COUNTERPART, COMM. LANG. 

Jim Totton 

Digital Equipment Corp. 

ZK02-3/K06 

110 Spit Brook Road 

Nashua, NH 03062 

ALT. ANSI X3J9 PASCAL STDS. COMM. 

Phil Wirth 

E-Systems, Garland Division 
Box 660023, MS 53730 
Dallas, TX 75266-0023 

(214) 272-0515 x4319 

ALT. ANSI X3J4 COBOL STDS. COMM. 

Dale Marriott 

El Paso County Office Bldg. 

27 E. Vermijo Street 
Colorado Springs, CO 80903 
(303) 520-6435 

CHAIR, DIBOL WORKING GROUP 

ASSOC, W/G COORD. UNSCHEDULED TOPICS 

ACTING CHAIR, COBOL WORKING GROUP 

Bruce Mebust 

Burlington Northern Railroad 
176 East Fifth Street 
P.O. Box 64962 
St Paul, MN 55164 
(612) 298-2382 


CHAIR, SECURITY WORKING GROUP 

Rich Harris 

General Research Corp. 

5383 Hollister Avenue 
P.O. Box 6770 

Santa Barbara, CA 93160-6770 
(805) 964-7724 

ASSISTANT CAMPGROUND COORD. 

Tom J. Jeffrey 

Rockwell International Corp. 

1225 N. Alma Road 
Richardson, Texas 75081 
(214) 996-7818 

CHAIR, ADA WORKING GROUP 

Lisa Kerby-Rodgers 
GTE Government Systems 
100 Ferguson Drive 
P.O. Box 7188 
Mountain View, CA 94039 
(415) 966-2720 

CHAIR, PROJECT MANAGEMENT W/G 

Lynn C. Lewis 

Lawrence Livermore National Lab. 
University of California 
P.O. Box 808 
Livermore, CA 94550 
(415) 422-8949 

TEMP. CHAIR, OBJ. ORIENTED DES. W/G 
Frank B. Modruson 
Arthur Andersen & Co. 

33 West Monroe Street 
Chicago, IL 60603 
(312) 580-0033 

CHAIR, TeX/LaTEX WEB W/G 
John Osudar 
Argonne National Lab. 

9700 South Cass Avenue 
Argonne, IL 60439 
(312) 972-7505 
CHAIR, VAXset W/G 
David J. Powell 
The Upjohn Company 
7263-267-712 
301 Henrietta St 
Kalamazoo, MI 49007 
(616) 344-3341 

MEM., ANSI DIBOL X3J12 Stds. Comm. 
Kenneth Schilling 
2314 Mira Vista Avenue 
Montrose, CA 91020 
(818) 249-0795 

SUITE & RECEPTION COORD. 

Matt Variot 
Eaton Corporation 
Box 5009 

31717 La Tienda Drive 
Westlake Village, CA 91359 
(818) 706-5388 

CHAIR, TPU/EVE/LSE W/G 
John Wilson 
Aetna Life & Casualty 
City Place YFB3 
Hartford, CT 06103 
(203) 275-2064 
VICE CHAIR 

SYMPOSIUM LOGISTICS COORD. 

Terry Medlin 
Survey Sampling, Inc. 

1 Post Road 
Fairfield CT 06432 
(203) 255-4200 

MASTERS COORDINATOR 

Dena Shelton 
Cullinet Software Inc. 

2860 Zanker Rd, Suite 206 
San Jose, CA 95134 
(408) 434-6636 

ACTING CHAIR, APL WORKING GROUP 
CHAIR, BASIC W/G 
WISHLIST COORDINATOR 

Bob Van Keuren 
UserWare International, Inc. 

2235 Meyers Ave 
Escondido, CA 92025 
(619) 745-6006 


WORKING GROUPS COORD. 
CAMPGROUND COORDINATOR 
Joseph Pollizzi, III 
Space Telescope Science Institute 
3700 San Martin Drive 
Homewood Campus 
Baltimore, MD 21218 
(301) 338-4901 

CHAIR, SCAN WORKING GROUP 
CHAIR, PL/1 WORKING GROUP 
VOLUNTEERS COORD. 

David Ream 
Lexi-Comp 

26173 Tallwood Drive 
N. Olmsted, OH 44070 
(216) 777-0095 
(216) 468-0744 

CHAIR, PASCAL WORKING GROUP 
MEMBER, ANSI PASCAL X3 J9 STDS. COMM. 
CHAIR, MODULA-2 W/G 
E. Wayne Sewell 
E-Systems, Garland Div. 

Box 660023, MS 53700 
Dallas, TX 75266-0023 
(214) 272-0515 x3553 

CHAIR, SOFTWARE METRICS W/G 
Michael S. Terrazas 
LDS Church 

50 E. North Temple, 27th Floor 
Salt Lake City, UT 84150 
(801) 531-3246 

MEMBER, ANSI COBOL X3J4, STDS, COMM. 
Bruce Gaarder 
Donahue Enterprises, Inc. 

2441 26th Ave., S. 

Minneapolis, MN 55406 
(612) 721-2418 

ALT. SEMINAR COMM REP. 

Janet E. Bressan 
Boeing Aerospace Co. 

P.O. Box 3999, MS3C-24 
Seattle, WA 98124 
(206) 773-9404 

CHAIR, RPG WORKING GROUP 

Charles Williamson 
Hargray Telephone Co. 

P.O. Box 5519 

Hilton Head Is., SC 29938 

(803) 686-1204 

SEMINAR COMMITTEE REP. 

Barry C. Breen 

Sundstrand Data Control, Inc. 

15001 N.E. 36th Street 
P.O. Box 97001 
Redmond, WA 98073-9701 
(206) 885-8436 

ASSIST. MASTERS COORD. 

CLINIC DIRECTOR 

CHAIR, CASE & TOOLS INTEGRATION W/G 

George Scott 
Computer Sciences Corp. 

304 West Route #38, P.O. Box N 
Moorestown, NJ 08057 
(609) 234-1100 

ASSISTANT CAMPGROUND COORD. 

Keith Batzel 
Crowe, Chizek & Co. 

330 E. Jefferson 
Box 7 

South Bend, IN 46624 
(219) 232-3992 

DEVEL. COUNTERPART TECH. LANG. 

Leslie J. Klein 
Digital Equipment Corp. 

ZK02-3/N30 
110 Spit Brook Road 
Nashua, NH 03062 
DIGITAL COUNTERPART 
Celeste La Rock 
Digital Equipment Corp. 

ZK02-3/Q08 

110 Spit Brook Road 

Nashua, NH 03062 
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LARGE SYSTEMS 

CHAIR 

E.F. Berkley Shands 
Washington University 
Department of Computer Science 
P.O. Box 1045 
St. Louis, MO 63136 
(314) 889-6636 

UUCP: BERKLE Y@ WUCS. UUCP 
BITNET: Berkley@Uunet 
COMMUNICATIONS REPRESENTATIVE 
NEWSLETTER EDITOR 
Clyde T. Poole 

The University of Texas at Austin 
Department of Computer Sciences 
Taylor Hall 2.124 
Austin, TX 78712-1188 
(512) 471-9551 

ARPANET/CSNET:ctp@ sally, utexax.edu 
36 BIT SYSTEMS 

Clive Dawson 

Microelectronics & Computer Technology Corp. 

9430 Research Blvd. 

Echelon Bldg. #1, Suite 200 
Austin, TX 78759 
(512) 343-0860 

ARPANET/CSNET: CLIVE @ MCC. COM 

SYMPOSIUM REPRESENTATIVE 

Vacant 

DISTRIBUTED SYSTEMS 

Don Kassebaum 
Computation Center 
University of Texas at Austin 
Austin, TX 78712 
(512) 471-3241 

ARPANET: CC.KASSEBAUM@ A20.CC.UTEXAS.EDU 
SEMINARS REPRESENTATIVE 
Robert C. McQueen 
(201) 428-4242 

ARPANET: SIT.MCQUEEN@cu20B.COLUMBIA.EDU 
SUPERCOMPUTING 
Vacant 

SIG VICE-CHAIRMAN 

Ralph M. Bradshaw 
Johnson & Johnson 
Research & Scientific Services 
Management Information Center 
Raritan, NJ 08869-1489 
(201) 685-3434 

LIBRARY REPRESENTATIVE 
SIR/MENU BALLOT 

Jack Stevens 
The Gillette Company 
Technical Services, 4U-3 
1 Gillette Park 
Boston, MA 02106-2131 
(617) 463-2089 
SIG MARKETING 
Steve Attaya 
Weiner Enterprises 
P.O. Box 23607 
Harahan, LA 70183 
(504) 733-7055 

ARPANET: G.ATTAYA@R20.UTEXAS.EDU 
CORPORATE ISSUES 
Ralph Bradshaw 
Johnson & Johnson 
Research and Scientific Services 
Management Information Center 
Raritan, NJ 08869-1489 
(201) 685-3434 
DEC COUNTERPARTS 
Dave Braithwaite 
Digital Equipment Corporation 
Marlboro, MA 
Rich Whitman 

Digital Equipment Corporation 
Marlboro, MA 
Reed Powell 

Digital Equipment Corporation 
Marlboro, MA 



MUMPS SIG 

CHAIRMAN 

Chris Richardson 
Richardson Computer Research 
P.O. Box 8744 
La Jolla, CA 92038 
(619) 488-6193 
NEWSLETTER EDITOR 
VICE-CHAIR 
COMMCOMM REP. 

Mark J. Hyde 

Advanced Computing Services 

209 Ardsley Drive 

DeWitt, NY 13214 

BITNET: MJHYDE@ SUNRISE 

INTERNET: MJHYDE@ SUNRISE.ACS. SYR. EDU 

(315) 446-7223 

SYMPOSIUM SCHEDULER 
Brad Hanson 
Group Health, Inc. 

2829 University Ave., S.E. 

Minneapolis, MN 55414 
(612) 623-8427 

LIBRARY REPRESENTATIVE 
PDP-11 WORKING GROUP REP. 

Michael McIntyre 
PRx, Inc. 

43 Bradford Street 
Concord, MA 01742 
(617) 369-3566 

SEMINARS REPRESENTATIVE 
Edward Woodward 
Science Applications IntL Corp. 

10260 Campus Point Drive MS42 
San Diego, CA 92121 
(619) 535-7210 

CAMPGROUND COORDINATOR 
ASSIST. SYMPOSIUM SCHEDULER 
Jerry Hsu 
Rubicon Corp. 

1200 E. Campbell 
Richardson, TX 75083 
(214) 231-6591 

SESSION NOTES EDITOR 
Bob Van Keuren 
4087 Chamoune Avenue 
San Diego, CA 92105 
(619) 283-5285 
PAST CHAIR 

MUMPS DEV. COMMITTEE REP. 

Mark Berryman 
Digital Equipment Corp. 

3 Results Way (MR03-2/H7) 

Marlborough, MA 01752 
(617) 467-4875 

BITNET: BERRYMAN@DSM.DEC.COM 
DEC COUNTERPART 
Dave Smith 

Digital Equipment Corp. 

2 Iron Way (MR03-2/H7) 

Marlborough, MA 01752 
(617) 467-2397 

ALTERNATE DEC COUNTERPART 

Denise Simon 
Digital Equipment Corp. 

129 Parker Street (PK02-1/M23) 

Maynard, MA 01754 
(617) 493-9077 



NETWORKS SIG 

CHAIRMAN 

Stuart Lewis 
Douglas Furn. Corp. 

(312) 458-1505 

COMMUNICATIONS COMMITTEE REP. 
Bob Gustafson 
Northeast Utilities 
(203) 665-5082 
NEWSLETTER EDITOR 
Judi Mandl 

UCONN Health Center 
263 Farmington Ave. Bldg. 19 
Farmington, CT 06032 
SEMINAR UNIT REP & 

VICE (BACKUP) SIG CHAIR 
Sandy Traylor 
Target Systems, Inc. 

(714) 921-0112 

SYMPOSIA COORDINATOR 
Bill Hancock 
(817) 261-2283 

STANDARDS COORDINATOR 
Jim Ebright 
Software Results Corp. 

(614) 267-2203 

ASSISTANT NEWSLETTER EDITOR 
Judi Mandl 
UConn Health Center 
(203) 674-3912 

SESSION NOTES EDITOR 
Mary Marvel-Nelson 
General Motors Research Lab. 

(313) 986-1382 
DEC COUNTERPART 
Monica Bradlee 
(617) 486-7341 



OFFICE AUTOMATION SIG 

CHAIR 

Katherine “Kit” Trimm 
Pivotal, Inc 
Tucson, AZ 
(602) 886-5563 
VICE CHAIRMAN 

Ralph Bradshaw 
Johnson and Johnson 
Raritan, NJ 
(201) 685-3434 

COMMUNICATIONS REPRESENTATIVE 
Mary Jane Bolling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 

SYMPOSIA COORDINATOR 
Mitch Brown 
GenRad, Ind. 

Waltham, MA 
(617)369-4400x3052 
NEW MEMBER COORDINATOR 
Tricia Cross 

American Mathematical Society 
P.O. Box 6248 
Providence, RI02940 
(401) 272-9500 
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BOF COORDINATOR 

Ray Kaplan 
PIVOTAL, Inc. 

Tucson, AZ 
(602) 886-5563 
NEWSLETTER EDITOR 
Therese LeBlanc 
T.M. LeBlanc & Assoc. 

Wheeling, IL 
(312) 459-1784 
LIBRARY 

Bob Hassinger 

Liberty Mutual Research Center 
Hopkington, MA 
(617) 435-9061 

OA TAPE COORDINATOR 
Mary Jane Boiling 
Foreign Mission Board 
3806 Monument Avenue 
Richmond, VA 23230 
(804) 353-0151 
SYMPOSIA ASSISTANT 
Sal Gianni 
Northeast Utilities 
Hartford, CT 
(203) 665-5652 
STORE COORDINATOR 
Mike Jackson 
Air Force Operational 
Test and Evaluation Center 
Kirtland AFB.NM 
(505) 846-5641 

PERSONAL COMPUTER SIG LIAISON 

Cheryl Johnson 
Grinnell College 
Grinnell, IA 
(515) 236-2570 

OA LUG COORDINATOR 

Tom Orlowski 

American Council on Education 
1 DuPont Circle (Suite 110) 
Washington, DC 
(202)939-9371 

OA SIG COORDINATOR 
Joe Whatley 
Neilson Media Research 
375 Patricia Avenue 
Dunedin, FL 33528 
(813)734-5473 

SESSION NOTE EDITOR 
George Bone 
194 Nalisty Drive 
Vallejo, CA 94590 
(707) 646-2531 



PERSONAL COMPUTER SIG 

CHAIR 

Lynn Jarrett 

San Diego Union-Tribune Pub. Co. 

350 Camino de la Reina 
San Diego, CA 92108 
(619) 293-1130 

WORKSTATIONS/MACS/PRO 
WORKING GROUP CHAIRMAN 

Thomas R Hintz 
Univ. of Florida 
IFAS Computer Network, 

Bldg, 120 

Gainesville, FL 32611 
(904) 392-5180 

VICE, CHAIR RAINBOW W/G CHAIRMAN 
Lynn Jarrett 

Union Tribune Publishing Co. 

P.O. Box 191 
San Diego, CA 92108 
(619) 299-3131 xll30 


VAXMATE WORKING GROUP CHAIRMAN 

Frederick G. Howard 
Eastman Kodak Company 
901 Elmgrove Road, D345-LP 
Rochester, NY 14650 
(716) 253-2363 

VOLUNTEER COORDINATOR 
Pierre M. Hahn 
SUNY HSC-T10-028-8101 
Stony Brook, NY 11794 
LIBRARIAN Rep. 

Ron S. Hafner 
Hafner and Associates 
P.O. Box 2924 
2499 Wellingham Dr. 

Livermore, CA 94550 
(415) 422-2149 

COMMUNICATIONS REPRESENTATIVE 
Kenneth LeFebvre 
Sytek, Inc. 

19 Church St 
P.O. Box 128 
Berea, OH 44017 
(216) 243-1613 
NEWSLETTER EDITOR 
Gary Rice 
McDonnell Douglas 
5555 Garden Grove Blvd. 

MS: K200 77/200 
Westminster, CA 92683 
(714) 952-6582 

RAINBOW/DECmate W.G. CHAIR 
Vince Perriello 

Crosfield Composition Systems 
One Crosfield Ave. 

West Nyack, NY 10994 
(914) 353-4000 

SYMPOSIA COORDINATOR 
Jimbo Wilson 
Natl Tech. Inst for Deaf 
Rochester Inst of Tech. 

P.O. Box 9887 
Rochester, NY 14623 
(716) 475-6241 

SESSION NOTES EDITOR 
Dr. Tom. Warren 
Oklahoma State Univ. 

Dept of English 
Dir. Tech. Writing Program 
Stillwater, OK 74078 
(405) 624-6138 

PCS A WORKING GROUP CHAIRMAN 
To be announced 
MEMBERS-AT-LARGE 
Michael Bowers 
Univ. of California 
Animal Science Department 
Davis, CA 95616 
(916) 752-6136 
Theodore Needleman 
Odea Tech. 

67 W. Burda PI. 

Spring Valley, NY 10977 
(914) 250-100 

DEC COUNTERPARTS 
PERSONAL COMPUTING SYSTEMS GROUP 
Anita Uhler 

Digital Equipment Corporation 

LJ02/13 

30 Porter Road 

Littleton, MA 01460 

(617) 486-2397 

PRO 

Jeff Slay back 
Digital Equipment Corp. 

ML021-2/U12 
146 Main Street 
Maynard, MA 01754 
(617) 493-9340 

BUTTON COORDINATOR 

Ken Strieker 

Martin Marietta Aerospace 
P.O. Box 5837 MP 320 
Orlando, FL 32855 
(305) 356-6589 


CAMPGROUND COORDINATOR 

Jim Hobbs 
Adolf Coors Co. 

Golden, CO 80401-1295 
(303) 277-2855 

SEMINARS COORDINATOR 

Tim Bundrick 
3480 TCHTW/TTVC 
Goodfellow AFB.TX 76908-5000 
(915) 657-5424 



RSTS SIG 

CHAIRMAN 

Charles Mustain 
Stark County School system 
Data Services Division 
7800 Columbus Rd. N.E. 

Louisville, OH 44641 
(216) 875-1431 

COMMUNICATIONS REPRESENTATIVE 
STORE REPRESENTATIVE 
Ed Beadel 

Instructional Computer Center 
S.U.N.Y. College at Oswego 
Oswego, N.Y. 13126 
(315) 341-3055 

SYMPOSIA COORDINATOR 

Glenn Dollar 

Digital Computer Consultants Inc. 

21363 Lassen St, Suite 205 
Chatsworth, CA 91311 
(818) 341-9171 

ASS’T SYMPOSIA COORDINATOR 
Dan Stoller 

Natural Country Farms 
P.O. Box 758 
58 West Road 
Rockville, CT 06066 
(203) 872-8346 
NEWSLETTER EDITOR 

Terence M. Kennedy 
St Peter’s College 
Department of Computer Science 
2641 Kennedy Blvd. 

Jersey City, NJ 07306 
(201) 435-1890 

LIBRARY REPRESENTATIVE 

RR. Patel (PAT) 

Krupp/TaylorUSA 
12800 Culver Blvd 
Los Angeles, CA 90066 

(213) 306-3646 

PRE-SYMPOSIA SEMINAR COORDINATOR 

Scott Castleberry 
1750 North Collins 
Suite 108 

Richardson, TX 75080 

(214) 437-3477 
VICE CHAIRMAN 

WISH LISTS COORDINATOR 
Lynn ell Koehler 
Campus America 
POISE Prod. Ctr. 

201 North Nevada Avenue 
Roswell, NM 88201 
(505)625-5500 
EDUSIG LIAISON 

George Wyncott 

Purdue University Computer Center 
W. Lafayette, IN 
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RSTS PRODUCT PLANNING COORDINATOR 

Errol E. Ethier 

Information Design and Management, Inc. 
23 Hunting Avenue 
(617) 842-4220 
Shrewsbury, MA 01545 
DEC COUNTERPART 
Kathy Waldron 

Digital Equipment Corporation 
Continental Blvd. 

Merrimack, NH 03054 
MEMBERS-AT-LARGE 

Edward F. Beadel, Jr. 

Manager 

Instructional Computing Center 

S.U.N.Y. College at Oswego 

Oswego, NY 13126 

(315) 341-3055 

Mark Hartman 

Jadtec Computer Group 

546 W. Katella Avenue 

Orange, CA 92667 

(714) 997-8928 

Jeff J. Killeen 

Information Design & Management, Inc. 

31 Hopedale Street 
Hopedale, MA 01747 
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RSX SIG 

CHAIRMAN 

Dan Eisner 
Perkin-Elmer Corp. 

Garden Grove, CA 
SYMPOSIA COORDINATOR 
Rick Sharpe 
Toledo Edison 
Toledo, OH 

PRE-SYMPOSIUM SEMINAR COORDINATOR 
Hans Jung 
Associated Press 
New York, NY 

COMMUNICATIONS REPRESENTATIVE 
Jay Allen Bennett 
Logisticon, Inc. 

5035 Whitneyville Road 
Ada, MI 49301 
(616) 452-1823 
NEWSLETTER EDITOR 

MULTI PROCESSORS WORKING GROUP COORDINATOR 
Bruce Mitchell 

Machine Intelligence & Industry Magin 
Byron, MIN 

STORE COORDINATOR 

Jim Hopp 

Carlton Financial Computation 
South Bend, IN 
SESSION NOTE EDITOR 
Burt Janz 
BHJ Associates 
Nashua, NH 


WORKING GROUP CHAIR 

Evan Kudlajev 
Philadelphia Electric Co. 

Philadelphia, PA 

RSX GROUP CHAIR SOFTWARE CLINIC COORD. 

Roy S. Maull 
U.S. Air Force 
OffuttAFB, NE 

SOFTWARE CLINIC COORDINATOR 

Bruce Zielinski 
RCS 

Moorestown, NJ 

VOLUNTEER COORDINATOR 

Gary Maxwell 
U.S. Geological Survey 
Menlo Park, CA 

SRD WORKING GROUP COORDINATOR 

Bob Turkelson 

Goddard Space Flight Center 
Greenbelt, MD 

ACCOUNTING & PERFORMANCE WORKING GROUP COORD. 

Denny Walthers 
American McGaw 
Irvine, CA 

MENU COORDINATOR 

Ed Cetron 

Center for Biomedical Design 
Salt Lake City, UT 
MEMBERS-AT-LARGE 
Jim McGlinchey 
Warrenton, PA 
Jim Neeland 
Hughes Research Labs. 

Malibu, CA 

Anthony E. Scandora, Jr. 

Argonne National Laboratory 
Argonne, IL 
Ralph Stamerjohn 
Creve Coeur, MO 



RT-11 SIG 

CHAIRMAN 

John T. Rasted 
JTR Associates 
58 Rasted Lane 
Meriden, CT 06450 
(203) 634-1632 

COM. COM VOTING REP. 

COBOL CONTACT 
Bill Leroy 

The Software House, Inc. 

P.O. Box 52661 
Atlanta, GA 30355-0661 
(404) 231-1484 

STANDARDS COORDINATOR 

Robert Roddy 
Naval Ship Research Ctr. 
Bethesda, MD 20084 
(301) 227-1724 
MACRO CONTACT 

Nick Bourgeois 
NAB Software Services Inc. 
P.O. Box 20009 
Albuquerque, NM 87154 
(505) 298-2346 
NEWSLETTER EDITOR 
TECO CONTACT 

PRODUCT PLANNING CONTACT 
John M. Crowell 
Multiware, Inc. 

2121-B Second St Suite 107 
Davis, CA 95616 
(916) 756-3291 


LIBRARIAN 

Glenn Everhart 
Mt. Holly, NJ 

CAMPGROUND COORDINATOR 

Jerry Ethington 
Prolifix Inc. 

Frankfort, KY 
DEC COUNTERPARTS 
Lin Olsen 
Nashua, NH 
Dick Day 
Nashua, NH 

WORKING GROUP COORDINATOR 

Sharon Johnson 
Epidemiology 
Minneapolis, MN 


NETWORKING CONTACT 

Jim Crapuchettes 
Omnex Corp. 

2483 Old Middlefield Way 
Mountain View, CA 94043 
(415) 966-8400 
WISH LIST CONTACT 
UNIX/ULTRIX CONTACT 
Bradford Lubell 
LA. Heart Lab, UCLA 
10833 Le Conte Avenue 
Los Angeles, CA 90024-1760 
(213) 206-6119 
TSX & C CONTACT 
Jack Peterson 
Horizon Data Systems 
P.O. Box 29028 
Richmond, VA 23229 
(804) 740-9244 
RUNOFF CONTACT 
John Davis 

Naval Ship Research Center 
Code 2950 

Bethesda, MD 20084 
(301) 227-1592 
LUG CONTACT 

Ned Rhodes 

Software Systems Group 
2001 North Kenilworth St 
Arlington, VA 22205 
(703) 534-2297 

PERSONAL COMPUTERS 

Dennis V. Jensen 
AMES Labs. ISU/USDOE 
310 Metallurgy 
Ames, Iowa 50011 
(515) 294-4823 

SYMPOSIA COORDINATOR 
Milton Campbell 
Talisman Systems 
Drawer CP-255 
Manhattan Beach, CA 90266 
(213) 318-2206 

TAPE COPY GENERATION 
TAPE COPY DISTRIBUTION 
RT DECUS LIBRARY CONTACT 
Tom Shinal 
Syntropic Technology 
P.O. Box 198 
Waterford, VA 22190 
(703) 882-3000 

PRE-SYMPOSIUM SEMINAR 
RT-11 SUITE MANAGER 
Bruce Sidlinger 
Sidlinger Computer Corp. 
4335 N.W. Loop 410, #209 
San Antonio, TX 78229 

(512) DIG-ITAL 
BASIC CONTACT 

Ralston Barnard 
Div 7523 
Sandia Labs 

Alburquerque, NM 87185 
(505) 844-5115 

PRO RT-11 & HARDWARE 
Bill Walker 

Monsanto Research Corp. 
P.O. Box 32, A-152 
Miamisburg, OH 45342 

(513) 865-3557 
FORTRAN CONTACT 

Robert Walraven 
Multiware, Inc. 

2121-B 2nd St Suite 107 
Davis, CA 95616 
(916) 756-3291 
OTHER LANGUAGES 
Gary Sallee 
19912 Femglen Drive 
Yorba Linda, CA 92686 
(714) 970-2864 
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SITE SIG 

CHAIRMAN 

Timothy Fraser 

Specialized Bicycle Components 
15130 Concord Circle #77 
Morgan Hill, CA 95037 
(408) 779-6229 

SYMPOSIA COORDINATOR 
Sue Abercrombie 
48 Malilly Rd. 

Portland, ME 04103 
(207) 772-2837 

SESSION NOTE EDITOR 
LARGE SYSTEMS SIG LIAISON 
Gary Bremer 
Emerson Electric Co. 

8100 W. Florisant 
St. Louis, MO. 63136 
(314) 553-4448 
NEWSLETTER EDITOR 
NETWORKS SIG LIAISON 
OA SIG LIAISON 

Gregory N. Brooks 
Washington University 
Behavior Research Labs 
1420 Grattan St 
St Louis, MO. 63104 
(314) 241-7600 ext 257 
HARDWARE COORDINATOR 
HMS SIG Liason 
Emily Kitchen 
A.H. Robins Co. 

1211 Sherwood Ave. RT-2 
Richmond, VA 23220 
(804) 257-2925 

COMMUNICATIONS COMMITTEE REPRESENTATIVE 
AI SIG Liason 

Terry C. Shannon 
Digital Review 
160 State St 
6th Floor 

Boston, MA. 02109 
(617) 367-7190 

PRE-SYMPOSIA SEMINAR COORDINATOR 
Phillip Ventura 
STAFF MANAGEMENT 
Adam Zavitski 
Simmonds Precision ICD 
3100 Highland Blvd. 

Raleigh, NC. 27625 
(919) 872-9500 
MEMBERS-AT-LARGE 
Ann Goergen 
Texas Instruments 
13510 N. Central 
M/S 437 

Dallas, TX. 75266 
(214) 995-4629 
HMS SIG Liason 
RT SIG Liason 

David Hunt 

Lawrence Livermore National Lab 

MS L-230 

P.O. Box 808 

Livermore CA. 94550 

(802) 656-3190 

Gary Siftar 

Digital Equipment Corporation 
Tulsa, OK. 

DEC COUNTERPARTS 
Joe Allen 
Stow MA. 

Lil Holloway 
Bedford MA. 

Susan Porada 
Marlboro, MA. 



UNISIG 

CHAIRMAN 

Kurt L. Reisler 
Hadron Incorporated 
9990 Lee Highway 
Fairfax, VA 22030 
(703) 359-6100 
decvax Iseismo! hadron !klr 
SYMPOSIA COORDINATOR 
Stephen M. Lazarus 
Ford Aerospace & Communications 
3939 Fabian Way. MS X-20 
Palo Alto, CA 94303 
(415) 852-4203 
ihnp4!fortune!wdll!sml 
SESSION NOTES EDITOR 
William Cheswick 
New Jersey Institute of Tech. 
Computing Services 
323 Martin Luther King Blvd. 
Newark, NJ 07102 
(201) 596-2900 
bellcore! njitcccc !bc 
NEWSLETTER EDITOR 

Sharon Gates-Fishman 
NDC Corporation 
730 E Cypress Avenue 
Monrovia, CA 91016 
(818) 358-1871 
! amdahl! cit-vax! ndc! sgf 
COMMCOMM REPRESENTATIVE 
James W. Livingston, Jr. 

Measurex Automation Systems 
10411 Bubb Rd 
Cupertino, CA 95014-4150 
(408) 973-1800 x 766 
ihnp4!masl!jwl 

ADMINISTRATIVE DAEMON 

Dorothy A. Geiger 
The Wollongong Group 
49 Showers Drive, #451 
Mountain View, CA 94040 
(415) 948-1003 
ihnp4!decwrl!dgeiger 
TAPE LIBRARIAN 

Carl Lowenstein 

Marine Physical Laboratory 

Scripps Institute of Oc’graphy, P-004 

LaJolla, CA 92093 

(619) 294-3678 

|ihnp4,decvax,akgua,dcdwest,ucbvax] 
! sdcsvax Implvax! cdl 

USENET LIAISON 
STANDARDS COORDINATOR 

Ed Gould 
Mt.Xinu 
2910 7th St. 

Suite 120 

Berkley,CA 94710 
(415) 644-0146 
ucbvax!mtxinu!ed 

MINISTER WITHOUT PORTFOLIO 

Norman Wilson 
Bell Laboratories, 2C-529 
600 Mountain Avenue 
Murray Hill, NJ 07974 
(201) 582-2842 

| decvax,ihnp4)! research! norman 
SEMINARS COORDINATOR 
Steven Step an ek 
Computer Science Dept. 

School of Eng. & Computer Science 
18111 Nordhoff St. 

North ridge, CA 91330 
(818) 885-2799 or 3398 
ihnp4!csun!sgs 


DEC COUNTERPART 

Gary Oden 

Digital Equipment Corporation 
Continental Blvd, MK02 
Merrimack, NH 03054 
(603) 884-5111 
decvax! oden 



VAX SYSTEMS SIG 

SYMPOSIUM COORD., ASSISTANT 

David Cossey 
Computer Center 
Union College 
Schenectady, NY 12308 

SESSION NOTES EDITOR 

Ken Johnson 

Meridien Technology Corp. 

P.O. Box 2006 
St. Louis, MO 63011 
NEWSLETTER EDITOR 
Clyde Poole 
Univ. Texas/Austin 
Dept, of Computer Science 
Taylor Hall 2,124 
Austin, TX 78712-1188 
(512) 471-9551 

LIBRARY WORKING GROUP 

Glen Everhart 
25 Sleigh Ride Road 
Glen Mills, PA 19342 
VAXcluster WORKING GROUP 
Thomas Linscomb 
Computation Center 
University of Texas 
Austin, TX 78712 

NETWORK WORKING GROUP 

Bill Hancock 

Dimension Data Systems, Inc. 

P.O. Box 13557 
Arlington, TX 76094-0557 
MicroVAX WORKING GROUP 
Ray Kaplan 
Pivotal, Inc. 

6892 East Dorado Court 
Tucson, AZ 85715-3264 
(602) 886-5563 

SYSTEM IMPROVEMENT REQUEST (CORE) 

Mark D. Oakley 
Battelle Memorial Institute 
505 King Avenue 
Columbus, OH 43201-2669 
MULTIPROCESSOR WORKING GROUP 
Eugene Pal 
U.S. Army 

CAORA(ATORCATC) 

Fort Leavenworth, KA 

PRE-SYMPOSIUM SEMINAR COORD. HISTORIAN 

Jeff Jalbert 
JCC 

P.O. Box 381 
Granville, OH 43023 

PRE-SYMPOSIUM SEMINAR COORD. (ACTING) 

June Baker 

Computer Sciences Corp. 

6565 Arlington Blvd. 

Falls Church, VA 22046 

FIELD SERVICE WORKING GROUP 

Dave Slater 

Computer Sciences Corp. 

6565 Arlington Blvd 
Falls Church, VA 22046 
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LARGE SYSTEMS INTEGRATION WORKING GP 

Leslie Maltz 

Stevens Institute of Tech. 

Computer Center 
Hoboken, NJ 07030 
VOLUNTEER COORDINATOR 
Elizabeth Bailey 
222 CEB 

Tennessee Valley Authority 
Muscle Shoals, AL 35661 

COMMERCIAL WORKING GROUP 

Bob Boyd 

GE Microelectronics Center 
P.O. Box 13409, MS7T3-01 
Research Triangle Park, NC 27709-3049 
SECURITY 

C. Douglas Brown 
Sandia National Labs 
Division 2644 
P.O. Box 5800 

Albuquerque, NM 87185-5800 
MIGRATION AND HOST DEVELOPMENT 
VAXintosh WORKING GROUP 

Jim Downward 
KMS Fusion Incorporated 
P.O. Box 156D 
Ann Arbor, MI 48106 
REAL TIME/PROCESS CONTROL 
Dennis Frayne 
McDonnell Douglas 
5301 Bolsa Avenue 
Huntington Beach, CA 92646 
Larry Robertson 
Bear Computer Systems 
56512 Case Avenue 
North Hollywood, CA 
INTERNALS WORKING GROUP 
Carl E. Friedberg 
Seaport Systems, Inc. 

165 William Street, 9th Floor 
New York, NY 10038-2605 
COMMUNICATIONS ASSISTANT 
David L. Wyse 

Professional Business Software 
3680 Wyse Road 
Dayton, OH 45414-2539 

CAMPGROUND COORDINATOR 

Kirk Kendrick 
Shell Oil Co. 

333 Highway G, MS D-2146 
Houston, TX 77082-8892 
PAST CHAIR 

Marge Knox 
Computation Center 
University of Texas 
Austin, TX 78712 
SYSTEM MANAGEMENT 
Steve Tihor 
251 Mercer Street 
New York, NY 10012 
ADVISORS 

Joseph Angelico 

U.S. Coast Guard Detachment 

National Data Buoy Center 

NSTL Station, MS 39529-6000 

Art McClinton 

Mitre 

1820 Dolley Madison Blvd. 

McLean, VA 22102 
A1 Siegel 

Battelle Memorial Institute 
505 King Avenue 
Columbus, OH 43201-2693 
CHAIR (CORE) 

Susan T. Rehse 

Lockheed Missiles & Space Co. 

0/19-50, B/101, P.O. Box 3504 
Sunnyvale, CA 94088-3504 
VICE-CHAIR (CORE) 

WORKING GROUP COORD. 

Ross Miller 

Online Data Processing Inc. 

N 637 Hamilton 
Spokane, WA 99202 


SYMPOSIA COORD. (CORE) 

Jack Cundiff 

Horry-Georgetown Tech. College 
P.O. Box 1966 
Conway, SC 29526 

COMMUNICATION COORD. (CORE) 

David Wyse 

Professional Business Software 
3680 Wyse Road 
Dayton, OH 45414 
(513) 890-1800 x223 
LIBRARIAN 

Joseph L. Bingham 
Mantech International 
2320 Mill Road 
Alexandria, VA 22314 
LUG COORDINATOR (CORE) 

Dave Schmidt 

Management Sciences Associates 
5100 Centre Avenue 
Pittsburgh, PA 15232 
STORE REPRESENTATIVE 
G. Beau Williamson 
Rockwell International 
1200 N. Alma Road 
MIS 406-280 
Richardson, TX 75081 
(214) 996-5547 
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SUBMITTING ARTICLES TO HARD NEWS 


The purpose of HARD NEWS, the HMS SIG newsletter, is to 
serve as a forum to share information related to DEC 
hardware with the members of the SIG. As such, the 
existence of the newsletter is entirely dependent on your 
contributions. If you have an HHK item, a better or safer 
way to do something, product news, a tutorial article of 
general interest, etc., we would like to publish it in the 
newsletter. We hope that HARD NEWS will be published at 
least six times a year. 

You can submit material to the editor, Carmen Wiseman, or to 
the HMS SIG chair, Bill Walker. We can accept submissions 
in a wide variety of formats: 

o Items can be sent to the editor on VMS-format RX50s, 
TK50 cartridges, or IBM PC format 5 1/4" floppies. The 
SIG chair prefers RT-11 floppies but can handle any 
reasonable media. 

o Hard copy, like cash, is always acceptable. 
Camera-ready copy will save us a lot of typing, but we 
don't insist on it. You can also use the Hardware 
Submission Form in the "Questionnaires" section of the 
combined SIGs Newsletters. 

o Those of you with access to DCS can send things to 
WALKER or WISEMAN. DCS is usually checked on a daily 
basis. 

o You can reach the SIG chair on CompuServe as 
"Bill Walker 71066,24" or via EasyLink mailbox 62752448 
or MCI Mail account 333-1675. You can reach the editor 
via EasyLink mailbox 62960090 (be sure to say ATTN: or 
TO: Carmen Wiseman somewhere in the body of the 

message) . 

If you have anything to submit, send iti If it is a mess. 
But we can read it, we will get it into the newsletter 
somehow. Finally, if you have any questions about 
submitting material, call one of us. The telephone numbers 
are listed below. 


Contributions can be sent to: 


William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 
(513) 865-3557 (work) 

(513) 426-7094/0344 (home) 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 
(617) 375-4361 (work) 
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Ask the WOMBAT WIZARD 
Submission Form 

To submit a problem to the WIZARD, please fill out the form below 
and send it to: 


WW Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 


Name: _ DECUS Membership No. 

Affiliation:_ 

Address: 


Telephone Number:_ 

Statement of Problem: 


Please following the following guidelines when submitting support 
material: 

1. If you are trying to demonstrate a method or a concept, 
please simplify the procedures, records, and other information 
to the shortest form possible. 

2. Annotate your attachments. Simple comments or hand-written 
notes ("Everything worked until I added this statement.") go a 
long way toward identifying the problem. 

3. Keep an exact copy of what you send. And number the pages 
on both copies. But send everything that is related to your 
question, even remotely. 

4. If you would like a direct response or would like your 
materials returned, please don't forget to include a stamped, 
self-addressed envelope large enough to hold the materials you 
send. 


O 
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DATATRIEVE/4GL SIG 

Product Improvement Request Submission Form 


Submittor: 
Address: 


DECUS Membership Number: 
Firm: 


Phone: 


Product or Products: 


How to write a PIR 

A PIR should be directed at a specific product or group of 
products. Be sure to give the full name of the product(s) and 
version numbers if applicable. Describe the functionality you 
would like to see in as complete terms as possible. Don't assume 
that the PIR editors or software developers know how it is done 
in some other software product - state specifically how you want 
the software to function. Provide justification of your request 
and give an example of its use. If you can, suggest a possible 
implementation of your request. 


Abstract: (Please limit to one or two short sentences.) 


Description and Examples: (Use additional pages as necessary.) 


[Put my name and address on reverse side, thus:] 


PIR Editor, Philip A. Naecker 
Consulting Software Engineer 
3011 North Mount Curve Avenue 
Altadena, CA 91001 
USA 
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HARDWARE SUBMISSION FORM — A SIG INFORMATION INTERCHANGE 
Message 


Contact 

Name 

Address 


Telephone 


Type of equipment 


SUBMIT ANY TYPE OF HARDWARE PROBLEMS AND/OR FIXES. 


SEND TO: 

William K. Walker 
Monsanto Research Corp. OR 
P.O. Box 32 A-152 

Miamisburg, OH 45342 


Carmen D. Wiseman 
Digital Review 

Prudential Tower, Suite 1390 
800 Boylston Street 
Boston, MA 02199 
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Languages &c Tools SIG — Masters Directory 


16 


MASTERS APPLICATION 

Name:___Title_ 

Company:_ 

Address: . . 


Network Address: 


Phone: ( ) _ 

_Date: 


The Languages & Tools SIG has established the designation “LANGUAGES AND TOOLS MASTER”, to be applied 
to selected, qualified people willing to share their expertise in various subjects with others. Masters are people who are 
knowledgeable enough in one or more languages or tools to be comfortable answering questions about them. The 
qualifications of an L&T Master are: expertise in a specific area, a willingness to have his/her name published as a Master, 
and a willingness to volunteer services in different ways. Each product may have several Masters, and there is an overall 
Masters Coordinator who is a member of the L&T Steering Committee. 

Masters are asked to serve other users (and, under some circumstances, DEC), as a resource on products within their 
competence. In addition to being listed in the L&T Masters Directory (published in the newsletter) as available for 
occasional telephone consultation, Masters may act as ‘Doctors’ at Symposium Clinics, present Symposium sessions on the 
products of interest to them, field test products, interact with DEC product managers when appropriate, or act as a 
reference for a product for Digital salespeople. Especially on mature products, the SIG is anxious for knowledgeable users 
to offer product tutorial sessions at Symposia, and Masters can be of great help here. At Symposia, Masters will wear an 
identifying button bearing the legend “Ask Me About.” and the name of the language or tool in which he/she specializes. 

If you’d like to serve as an L&T Master, please mark the products on which you are willing to answer questions with 
an M (for Master). Please mark any other products running at your site with an 4 A (for “also running”) to provide 
users with a broader picture of your facilities. (Although not an L&T product, Mumps is included here at the request of 
the Mumps SIG as a service to Mumps users). You may request removal of your name from the Masters Directory at any 
time, although you may continue to be listed for a month or two, because of publication lead times. 

I am qualified to act as an L&T Master for the following products: [^] Mumps 



Debug 


Bliss 


CMS 


TPU 


C 



Pascal 


Basic 


MMS 


EVE 


Ada 1 



Fortran 


Cobol 


LSE 


EDT 


APL 



Document 


Dibol 


SCA 


TECO 


RPG 



VAX Notes 


Emacs 


PCA 


PL/I 


Scan 



Test Manager 
Runoff & DSR 
TfeX & IAT e X 
Cobol Generator 
Software Project Mgr 


Briefly describe your experience with those you checked. 


How long have you held your present position?_ 

Are you able to attend at least one symposium each year?_ 

Users are encouraged to seek assistance with products by calling appropriate Masters listed in the Directory. As a 
Master, your name and telephone number will be published in the Masters Directory, and users will call on you for limited 
help from time to time. Please check, below, any additional activities you might do: 

| | Field-test new versions of your product at your work site. 

| | Provide feedback on the product when needed by its DEC product manager. 

| [ Act as a reference for the product at the request of Digital Sales or Marketing people. 

Mail to: Dena Shelton, L&T SIG Masters Coordinator, Cullinet Software, Inc., 2860 Zanker Road, 
Suite 206, San Jose, CA 95134. 


*Ada is a trademark of the DoD 
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Languages &i Tools SIG 
WISHLIST QUESTIONNAIRE 

Name:-Title_ 

Company:_ 

Address:_ 


Network Address: 


Phone: ( ) _ 

_Date: 


The Languages & Tools SIG is principally concerned with the DEC and public domain software products listed 
below. If your request directly involves one of these products, please check which one (if you have more than one 
request, please use a separate form for each): 


Debug 
Pascal 
Fortran 
Document 
VAX Notes 


Bliss 

Basic 

Cobol 

Dibol 

Emacs 


CMS 

MMS 

LSE 

SCA 

PCA 


TPU 

EVE 

EDT 

TECO 

PL/I 


C 

Ada 1 

APL 

RPG 

Scan 


Test Manager 
Runoff & DSR 
TfcX & IAT e X 
Cobol Generator 
Software Project Mgr 


If your request or suggestion doesn’t relate to one of the products listed above, check which one of the following 
Language & Tools SIG topics it concerns: 



Newsletter 


Symposium Sessions 



Masters Program 


Working Group Activities 


— 

Information Folder 

Other L&T SIG topic: 

— 

SIG Tape 



Pre-Symposium Seminars 
Session Notes 
DECUS Store Item 


Wish List Request —brief description: 


Complete description—please explain your request thoroughly; don’t assume we know details of other products or 
services; give examples._ 


Mail to: Shava Nerad, L&T Wishlist Coordinator, MIT, 77 Mass Ave. W91-219A, Cambridge, MA 
02139; (617)253-7438 


1 Ada is a trademark of the DoD 
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DATAGRAMS are short messages, comments, requests, or answers 
that are published in NETwords. Please fill in the sections below 
and send the DATAGRAM to: 

JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what _ 

Signature:_Date:_ 


ou-ll 




Place I 
Stamp! 
Here ! 


JUDI MANDL 

UCONN HEALTH CENTER 

263 FARMINGTON AVENUE, BLDG. #19 

FARMINGTON, CT 06032 


IoW Here 
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Name (optional) 
Address (optional) 


RT-11 WISH LIST SURVEY 


DECUS Number (optional) 


1.1 

3.1 

3.7u _ 

3.13a 

5.1b 

1.2 

3.2a 

3.7v 

3.13b 

5.2a 

1.3 

3.2b 

_ 3.7w _ 

3.13c 

5.2b 

1.4 

3.2c 

3 .lx _ 

3.13d 

6.1 

1.5 

3.2d 

_ 3.7y _ 

3.14 

6.2a 

1.6 

3.2e _ 

___ 3.7z _ 

3.15 

I 6.2b 

1.7a 

3.3a 

3.7 aa 

3.16 

6.2c 

1.7b 

3.3b 

“ 3.7bb 

3.17a 

6.2d 

1.8 

3.3c 

3.7cc 

3.17b 

6.3 

1.9a 

3.3d 

3.7dd _ 

3.17c 

6.4a 

1.9b 

3.4a 

3.7 ee 

3.17d 

6.4b 

1.9c 

3.4b 

3.8a 

3.17e 

6.4c 

1.9d 

3.4c 

3.8b 

3.17f 

6.4d 

1.10 

3.5a 

3.8c 

3.18 

6.5 

1.11 

3.5b 

3.9a 

3.19a 

6.6a 

1.12 

3.6a 

3.9b 

3.19b 

_ 6.6b 

1.13 

_ 3.6b _ 

3.9c 

3.19c 

6.6c 

1.14 

3.6c 

3.9d 

4.1 

6.6d 

2.1 

_____ 3.6d _ 

3.9e 

4.2a 

I 6.7 

2.2 

3.6e 

3.9f 

4.2b 

6.8a 

2.3 

3.6f _ 

3.9g 

4.3 

6.8b 

2.4 

3.6g 

3.9h 

4.4a 

6.8c 

2.5 

3.7a 

I 3.9i _ 

4.4b 

J 6.8d 

2.6 

3.7b 

3.9 j 

4.5a 

6.8e 

2.7 

3.7c 

3.9k 

4.5b 

7. 

2.8 

3.7d 

3.10a 

4.6 

8. 

2.9 

3.7e 

3.10b 

4.7a 

9.1 

2.10 

3.7f 

3.10c 

4.7b 

9.2a 

2.11 

3.7g 

3. lOd 

4.7c 

9.2b 

2.12 

3.7h 

3. lOe 

4.7d 

9.3a 

2.13 

3.7i 

3. lOf 

4.7e 

9.3b 

2.14 

3.7 j 

3. lOg 

4.7f 

10.1 

2.15 

3.7k 

3. lOh 

4.7g 

10.2 

2.16 

3.71 

~ 3 . lOi _ 

4.7h 

10.3 

2.17 

3.7m 

3.10 j 

4.7i 


2.18 

3.7n 

3.10k 

4 • 7 j 


2.19 

3.7o _ 

1 3.101 _ 

4.7k 


2.20 

3.7p 

3.10m 

4.71 


2.21 

3.7q _ 

3. lOn 

4.7m 


2.22 

3.7r 

3.11a 

4.7n 


2.23 

3.7s 

3.11b 

" 4.7o _ 


2.24 

I 3.7t _ 

3.12 

5. la _ 



Send Responses to: RT-11 Wish List Survey 
Multiware, Inc. 

2121-B Second St. Suite 107 
Davis, CA 95616 
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DECUS U.S. CHAPTER 

SUBSCRIPTION SERVICE SIGS NEWSLETTERS ORDER FORM 

(U.S. Members Only) 



| DECUS 


| As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS monthly publication, SIGs 
| Newsletters. You also have the opportunity to subscribe to the Symposia Proceedings which are a compilation of the reports 
I from various speakers at the U.S. National DECUS Symposia. 

I • No Purchase Orders will be accepted. • No refunds will be made. 

I »The order form below must be used as an *The address provided below will be used for all DECUS 
invoice. mailings; i.e. Membership, Subscription Service and Symposia. 

, • All checks must be made payable to DECUS. • SIGs Newsletters Price is for a one-year subscription beginning 
i • All orders MUST be paid in full. the month following receipt of payment, 

j • Minimum of $25.00 for orders placed via a 
§' credit card. 


Name_ . _ __.. . DECUS Member# 

Company_ __ .. _ 

Address____....... .,, , .. 


City___ ______.. . State .. . Zip 

Telephone #_)_ 


Subscription Service Offering 

Unit Price 

Quantity 


Total 

SIGs Newsletters 

$35.00 

_ . 



Spring ’87 Proceedings (SP7) 

15.00 

. . - 

-- .... 


Fall '87 Proceedings (FA7) 

15.00 

. . - - - 

-....... 

.... _ 

Spring ’88 Proceedings (SP8) 

15.00 

- . ... . - 

_ . . 

- . - • - - 

Fall '88 Proceedings (FA8) 

15.00 

Total Amount 

$ _ 



j □ MASTERCARD □ VISA □ DINERS CLUB/CARTE BLANCHE® □ AMERICAN EXPRESS 
j Credit Card#_____Expiration Date 

; I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature .. 


FOR DIGITAL EMPLOYEES ONLY 


Badge #___. . Cost Center .... 

Cost Center Mgr. Name.._.... Cost Center Mgr. Signature 


MAIL TO: Subscription Service, DECUS(BP02), 219 Boston Post Road, Marlboro, MA 01752-1850, (508)480-3659. As of July 1, 
1988 the phone number will be (508) 480-3659 


FOR DECUS OFFICE ONLY 


Check Number____ . __ Bank Number . 

Amounts___^. 

S&M-l 
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DECUS 


DECUS U.S. CHAPTER 
APPLICATION FOR MEMBERSHIP 


□ New Membership □ Update to current membership profile Current DECUS Member.#_ 

Please provide a complete mailing address, include zip code in accordance with postal regulations for your locality. 

Are you an employee of Digital Equipment Corporation? □ YES □ NO 


NOTE: Please print clearly or type! 


Name:_ 

(First) (Middle Initial) (Last/Family Name) 

Company:_ 

Address:_ 


City/Town/State/Zip: 


Telephone: Home( 


Work( 


How Did You Learn About DECUS? Please Check Applicable Item. 

iD ANOTHER DECUS MEMBER 4D DIGITAL SALES 

2 □ SYMPOSIA 5 □ HARDWARE PACKAGE 

8 □ DECUS CHAPTER OFFICE 6D SOFTWARE PACKAGE 

10 □ DIGITAL STORE 12 □ ADVERTISING 


13 □ LOCAL USERS GROUP 

14 □ SPECIAL INTEREST GROUP 

7 □ SOFTWARE DISPATCH (Digital Newsletter) 


; Do you wish to be included in mailings conducted by Digital (for marketing purposes etc?) DPermission 

□ Refusal 

Type Of Digital Hardware Used: Please Check Those Applicable To You. 


20 □ 

DECMATE 


52 □ LSM 1 


21 □ 

PROFESSIONAL 5 0 

WPS-8 


82 □ 

DECSYSTEM-10 

3 □ PD P-8 FAMILY 

22 □ 

RAINBOW 

51 □ 

WPS-11 


83 □ 

DECSYSTEM-20 

50 □ PDP-11 

FAMILY 

54 □ 

VAX FAMILY 




Major Operating Systems? Languages Used: Please Check Those Applicable To You. 



i □ 

ADA 

26 □ 

CORAL-66 

47 □ 

FOCAL 

67 □ 

OS/8 

109D 

RT-11 

2 □ 

ALGOL 

28 □ 

COS 

48 □ 

FORTRAN 

68 □ 

PASCAL 

97 □ 

TECO 

5 □ 

APL 

34 □ 

DATATRIEVE 

51 □ 

GAMMA 

72 □ 

PL-11 

70 □ 

TOPSrIO 

?□ 

BASIC 

35 □ 

DBMS 

non 

IAS 

92 □ 

RPG 

71 □ 

TOPS-20 

17 □ 

BLISS 

38 □ 

DECNET 

53 □ 

IQL 

81 □ 

RSTS/E 

111 □ 

ULTRIX/UNIX 

19 □ 

C 

43 □ 

DIBOL 

58 □ 

MACRO 

83 □ 

RSX 

104D 

VMS 

22 □ 

COBOL 

45 □ 

DOS-11 

65 □ 

MUMPS 

91 □ 

RMS 

107D 

WPS-8 
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Type Of Business (Environment)/Computer Applications 

Please Check That Which Best Describes Your Business/Application. 


21 

□ 

ACCOUNTANCY 

i □ 

EDUCATION/PRIMARY 

23 □ 

NUMERICAL CONTROL 

7 

□ 

BANK 

2 □ 

EDUCATION/SECONDARY 

68 □ 

OEM-COMMERCIAL 

64 

□ 

BUSINESS/COMMERCIAL 

61 □ 

EDUCATION-TECHNOLOGY 

78 □ 

OEM-TECHNICAL 

74 

□ 

BUSINESS/INFORMATION SYSTEMS 

3 □ 

EDUCATION/UNIVERSITY 

56 □ 

PHYSICAL SCIENCES 

57 

□ 

CHEMISTRY 

67 □ 

ENGINEERING 

20 □ 

RESEARCH/DEVELOPMENT 

54 

□ 

CLINICAL LABORATORY 

65 □ 

FINANCE/ACCOUNTING 

ioD 

RETAIL 

63 

□ 

COMPUTATION 

77 □ 

GOVERNMENT 

73 □ 

SOFTWARE DEVELOPMENT 

11 

□ 

CONSUMER ELECTRONICS 

75 □ 

GRAPHICS 

53 □ 

TELECOMMUNICATIONS 

18 

□ 

CONSULTANT 

4 □ 

HOSPITAL 

19 □ 

TELEPHONE/UTILITIES 

72 

□ 

DATA ACQUISITION 

62 □ 

INDUSTRIAL 

51 □ 

TIMESHARING 

52 

□ 

DATA COMMUNICATIONS 

55 □ 

LABORATORY/SCIENTIFIC 

80 □ 

TRAINING/INSTRUCTION 

13 

□ 

DATA PROCESSING SERVICES 

14 □ 

LIBRARY 

66 □ 

TYPESETTING/PUBLICATION 

71 

□ 

DATA REDUCTION 

58 □ 

LIFE SCIENCES 



17 

□ 

DIGITAL EMPLOYEE-ENGINEERING 

70 □ 

MANUFACTURING 



15 

□ 

DIGITAL EMPLOYEE-MARKETING 

79 □ 

MARKETING 



16 

□ 

DIGITAL EMPLOYEE-SERVICE GROUP 

59 □ 

MEDICAL RESEARCH 



60 

□ 

EDUCATIONAL ADMINISTRATION 

6 □ 

MILITARY INSTALLATION 




Special Interest Groups(SIGs) Enrollment 

I Wish To Participate In The Following DECUS U. & Chapter Special Interest Groups. 


3 □ 

ARTIFICIAL INTELLIGENCE 

ii □ 

HARDWARE AND MICRO 

36 □ 

PERSONAL COMPUTER 

7 □ 

BUSINESS APPLICATIONS 

35 □ 

IAS 


18 □ 

RSTS/E 

2 □ 

COMMERCIAL LANGUAGES 

27 □ 

LARGE SYSTEMS 


17 □ 

RSX 

6 □ 

DATA MGMT SYSTEMS 

16 □ 

L & T 


19 □ 

RT-11 

31 □ 

DAARC (LABS) 

14 □ 

MUMPS 


32 □ 

SITE MGMT & TRNG 

5 □ 

DATATRI EVE/4 GL 

15 □ 

NETWORKS 


21 □ 

UNISIG 

8 □ 

EDUSIG 

34 □ 

OFFICE AUTOMATION 


26 □ 

VAX 

10D 

GRAPHICS APPLICATIONS 






Job Title/Position- Please Check: 






i □ 

CORPORATE STAFF 



101 □ 

CORPORATE DIRECTOR OF DP/MIS 

2 □ 

DIVISION OR DEPARTMENT STAFF 


102D 

ADMINISTRATIVE ASSISTANT 

3 □ 

SYSTEMS ANALYSIS 



103 □ 

TECHNICAL ASSISTANT 

4 □ 

APPLICATIONS PROGRAMMING 



104D 

SERVICES COORDINATOR 

5 □ 

SYSTEMS ANALYSIS/PROGRAMMING 


105D 

MANAGER 

6 □ 

OPERATING SYSTEM PROGRAMMING 


106 □ 

ANALYST 

7 □ 

DATABASE ADMINISTRATION 



107 □ 

PROGRAMMER 

8 □ 

DATA COMMUNICATIONS/TELECOMMUNICATIONS 

108 □ 

DATABASE MANAGER 

9 □ 

COMPUTER OPERATIONS 



109 □ 

DATABASE ADMINISTRATOR 

10D 

PRODUCTION CONTROL 



HOD 

MANAGER OF DP OPERATIONS 


| Citizen of The United States of America? □ YES □ NO Country:. 


Signature:. 


Forward To: 


. Date:. 


DECUS U. S Chapter 

Digital Equipment Computer Users Society 

Membership Processing Group 

219 Boston Post Road, BP02 

Marlboro, MA 01752-1850 

Phone: (617)480-3418 

DTN: 8-296-3418 
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NOTES 




NOTES 



NOTES 




NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



NOTES 



Printed in the U.S.A. 


“The Following are Trademarks of Digital Equipment Corporation” 


Cl 

Micro VMS 

TOPS-20 

DATATRIEVE 

PDP-11 

ULTRIX-32 

DEC 

PD P-11/24 (et. al) 

UNIBUS 

DECmate 

P/OS 

VAX 

DECnet 

RALLY 

VAXcluster 

DECserver 

RSX 

VAXstation 

FOCAL 

RSX-11S 

VAX/VMS 

IAS (etal) 

RSX-11M-PLUS 

VMS 

LAN Bridge 

RSTS/E 

VT 

LN03 

RT-11 

VT50 (et.al) 

Micro/RSX 

TOPS-10 



Copyright®DECUS and Digital Equipment Corporation 1988 
All Rights Reserved 

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equip¬ 
ment Corporation or DECUS. Digital Equipment Corporation and DECUS assume no responsibility for any errors that may appear 
in this document. 

It is assumed that all articles submitted to the editor of this newsletter are with the authors’ permission to publish in any DECUS 
publication. The articles are the responsibility of the authors and, therefore, DECUS Digital Equipment Corporation, and the editor 
assume no responsibility of liability for articles or information appearing in the document. The views herein expressed are those of 
the authors and do not necessarily express the views of DECUS or Digital Equipment Corporation. 

AT&T is a trademark of American Telephone & Telegraph Company; IBM is a registered trademark of International Business 
Machines Corporation; RMS is a trademark of American Management Systems, Inc.; TSX-PLUS is a trademark of S&H computer 
Systems, Inc.; UNIX is a registered trademark of American Telephone & Telegraph Company. 


Production Staff: 

Beverly Welborne: Communications Committee Chair 
R.E. Center 

Frank Borger: SIG Publications Chair 
Michael Reese Hospital 

Judy Mulvey: Publications Manager 
DECUS 

Judy Tessien Phototypographer/Graphics Designer 
DECUS 


Circulation: 6135 
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STATUS CHANGE 

Please notify us immediately to guarantee 
continuing receipt of DECUS literature. Allow 
up to six weeks for change to take effect. 

( ) Change of Address 

( ) Please Delete My Membership Record 

(I Do Not Wish To Remain A Member) 

DECUS Membership No:___ 

Name:_ 

Company: ___— 

Address:_ 


State/Country: __ 
Zip/Postal Code: 


Mail to: DECUS - Attn: Subscription Service 
219 Boston Post Road, BP02 
Marlboro, Massachusetts 01752-1850 

USA 


-J 


CD O 
O 


D> B> S’ > 
O ft) Q. < <D =* 

3 3??-3x 

■O <t> CD 0) ■ 

o> w cr - 

o 2. w s* 3 

< U ™ — ft) 

= CD »» = 

CD oT o w _ 

*• 5 S o 3 * 

^ P m a 2 ® 



DECUS SUBSCRIPTION SERVICE 
DIGITAL EQUIPMENT COMPUTER SOCIETY 
219 BOSTON POST ROAD, (BP02) 
MARLBORO, MA 01752*1850 








